Resource protection and verification with bidirectional notification architecture

ABSTRACT

A method of verifying resource protection statuses for resources for address-based resources may include receiving a request for verification of resource protection from a client device for an address-based resource. The request includes an address of a resource. The intermediate system is programmed to receive resource protection verification requests from a plurality of client devices, and to receive resource protection verifications from a plurality of resource protection systems that are in communication with the intermediate system. The method also includes determining that none of the resource protection systems in the plurality of resource protection systems currently protect the resource; retrieving information that is securely stored for the resource and a user associated with the request; and sending the information to one or more of the plurality of resource protection systems as a request to protect the resource.

CROSS-REFERENCES TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application62/667,943 filed on May 7, 2018, which is incorporated herein byreference. This application also claims the benefit of U.S. ProvisionalApplication 62/844,667 filed on May 7, 2019, which is incorporatedherein by reference.

TECHNICAL FIELD

This application discloses technology related to the fields of verifyingthe protection of a resource through a network session. In particular,this technology stores data subsets from multiple resource protectionsystems at a central server such that resource protection can beverified in real-time.

BACKGROUND

Resources can be protected by a number of different methods. Differentstandards and/or organizations may use different resource protectionpolicies to guarantee that resources are adequately protected.Furthermore, a multitude of different resource protection systems may beavailable for general resource protection, and may be made available toresource owners through a network interface. These different resourceprotection systems may be spread across different servers operated bymany different entities. Each of the resource protection systems and/oreach of the particular protection policy employed by the systems may beindividually tailored to particular resources or locations. Because eachresource protection policy may be unique in at least a few respects, themethods of characterizing these protection policies and determiningwhether they meet external requirements for resource protection are asvaried as the resource protection policies themselves.

Because of the relative importance of resource protection, someprocesses rely on the verification of a resource protection policy beingin place before allowing a process to continue. When a process isinitiated, the process may be paused in order to verify that an adequateresource protection policy is in place or any resources that may beaccessed or affected by the process. Verifying that a resourceprotection policy is active requires the process to pause and send thecommunication request to the specific resource protection systemcurrently employed to protect the resource.

SUMMARY

In some embodiments, a method of verifying resource protection statusesfor resources for address-based resources may include receiving, by anintermediate system, a request for verification of resource protectionfrom a client device for an address-based resource. The request mayinclude an address of a resource. The intermediate system may beprogrammed to receive resource protection verification requests from aplurality of client devices, and to receive resource protectionverifications from a plurality of resource protection systems that arein communication with the intermediate system. The method may alsoinclude determining, by the intermediate system, that none of theresource protection systems in the plurality of resource protectionsystems currently protect the resource; retrieving, by the intermediatesystem, information that is securely stored for the resource and a userassociated with the request; and sending, by the intermediate system,the information to one or more of the plurality of resource protectionsystems as a request to protect the resource.

In some embodiments, a system may include one or more processors and oneor more memory devices comprising instructions that, when executed bythe one or more processors, cause the one or more processors to performoperations including receiving, at an intermediate system, a request forverification of resource protection from a client device for anaddress-based resource. The request may include an address of aresource. The intermediate system may be programmed to receive resourceprotection verification requests from a plurality of client devices, andto receive resource protection verifications from a plurality ofresource protection systems that are in communication with theintermediate system. The operations may also include determining, by theintermediate system, that none of the resource protection systems in theplurality of resource protection systems currently protect the resource;retrieving, by the intermediate system, information that is securelystored by the intermediate system for the resource and a user associatedwith the request; and sending, by the intermediate system, theinformation to one or more of the plurality of resource protectionsystems as a request to protect the resource.

In any embodiments, one or more of the following features may beimplemented in any combination and without limitation. The intermediatesystem may act as an intermediary to decouple requests from clientdevices from requests sent to the plurality of resource protectionsystems. The intermediate system may include a cloud-based system thatoperates on hardware and software that is different from any of theplurality of resource protection systems. The address of the resourcemay include a physical location of the resource. The method/operationsmay also include sending, by the intermediate system, an indication tothe client device that the resource is currently unprotected; andreceiving, by the intermediate system, an indication from the clientdevice that protection for the resource should be requested. Theindication from the client device that the resource is currentlyunprotected may include a list of one or more resource protectionsystems from the plurality of resource protection systems. An order ofthe list of one or more resource protection systems may be determinedbased on a predetermined priority level for each of the one or moreresource protection systems. An order of the list of one or moreresource protection systems may be determined based on a preferenceindicated by the user. The method/operations may also include receiving,by the intermediate system, a second request for verification ofresource protection from a second client device for a secondaddress-based resource; determining, by the intermediate system, thatone or more of the resource protection systems in the plurality ofresource protection systems currently protect the resource; sending antransmission to the one or more of the resource protection systemsindicating that the resource is being transferred to the user from aprevious user. Information that is securely stored by the intermediatesystem may include contact information for the user and the address ofthe resource. The method/operations may also include authorizing, by theintermediate system, the plurality of resource protection systems thatprovide protection for a plurality of different resources to provideperiodic uploads to the intermediate system; receiving, by theintermediate system, periodic uploads of information associated withprotected resources from the plurality of resource protection systems,where the information associated with the protected resources mayinclude data subsets of full data sets stored at the plurality ofresource protection systems; and storing the data subsets in a databaseat the intermediate system. Determining, by the intermediate system,that none of the resource protection systems in the plurality ofresource protection systems currently protect the resource may includeusing the address of the resource, querying the database for a datasubset associated with protection of the resource. The method/operationsmay also include receiving an estimate of a data value for resourceprotection from one or more resource protection systems in the pluralityof resource protection systems; and sending the estimate of the datavalue to the client device. The method/operations may also includegenerating an estimate of a data value for resource protection, wherethe estimate may be based at least in part on data values received fromthe resource protection systems; and sending the estimate of the datavalue to the client device. The method/operations may also includesending a second request based on the request for verification ofresource protection to a subset of the plurality of resource protectionsystems, where the second request may be sent in response to receivingthe request for verification of resource protection. Themethod/operations may also include reformatting the request forverification of resource protection into a standard format for an APIused by the plurality of resource protection systems and specified bythe intermediate system. An indication of resource protection receivedfrom one of the plurality of resource protection systems may include aprotection start time and a protection interval. The information that issecurely stored by the intermediate system for the resource and the userassociated with the request may be used to populate a form.

In some embodiments, a method of efficiently storing and retrievingsubsets of resource protection information for low-latency retrieval mayinclude authorizing a plurality of resource protection systems thatprovide protection for a plurality of different resources to provideperiodic uploads, and receiving periodic uploads of informationassociated with protected resources from the plurality of resourceprotection systems. The information associated with the protectedresources may include data subsets of full data sets stored at theplurality of resource protection systems. The method may also includestoring the data subsets in a database, and receiving a request forverification of resource protection from a requesting system. Therequest for verification of resource protection may request at least onedata value, and may include an address of a resource. The method mayadditionally include, using the address of the resource, querying thedatabase for a data subset associated with protection of the resource,and returning at least a portion of the data subset to the requestingsystem. The at least a portion of the data subset may include the atleast one data value, and an identification of one of the plurality ofresource protection systems that provides protection for the resource.

In some embodiments, a system may include one or more processors, andone or more memory devices that my include instructions that, whenexecuted by the one or more processors, cause the one or more processorsto perform operations including authorizing a plurality of resourceprotection systems that provide protection for a plurality of differentresources to provide periodic uploads, and receiving periodic uploads ofinformation associated with protected resources from the plurality ofresource protection systems. The information associated with theprotected resources may include data subsets of full data sets stored atthe plurality of resource protection systems. The operations may alsoinclude storing the data subsets in a database, and receiving a requestfor verification of resource protection from a requesting system. Therequest for verification of resource protection may request at least onedata value, and may include an address of a resource. The operations mayadditionally include, using the address of the resource, querying thedatabase for a data subset associated with protection of the resource,and returning at least a portion of the data subset to the requestingsystem. The at least a portion of the data subset may include the atleast one data value, and an identification of one of the plurality ofresource protection systems that provides protection for the resource.

In any embodiments, one or more of the following features may beimplemented in any combination and without limitation. The database maystore data subsets from the plurality of resource protection systemsindexed at least in part by addresses of the associated resources. Theat least a portion of the data subset may further include a timeinterval associated with the protection of the resource. Querying thedatabase for the data subset associated with protection of the resourcemay include determining that there is no entry in the databaseassociated with the resource, submitting a query to at least one of theresource protection systems, and receiving an estimate of the at leastone data value from the at least one of the resource protection systems.The method/operations may also include generating an estimate based atleast in part on the received estimate of the at least one data valuefrom the at least one of the resource protection systems. Querying thedatabase for the data subset associated with protection of the resourcemay include determining that there is no entry in the databaseassociated with the resource, and generating an estimate of the at leastone data value. Generating the estimate of the at least one data valuemay be based at least in part on data subsets stored in the databasehaving addresses that are within a predetermined range of the address ofthe resource. Generating the estimate of the at least one data value maybe based at least in part on data subsets stored in the database havingresources with characteristics that are similar to characteristics ofthe resource. The method/operations may also include receiving asubsequent request for a full data set for the resource, submitting aquery to a resource protection system indicated by an entry in the datasubset for the resource stored in the database, receiving the full dataset for the resource from the resource protection system, and returningthe full data set to the requesting system. The method/operations mayalso include generating a statistical comparison between the at leastone data value and other data values stored in the database, and sendingan indication of the statistical comparison to the one of the pluralityof resource protection systems. The method/operations may also includesending an indication to the one of the plurality of resource protectionsystems in response to receiving the request for verification ofresource protection from the requesting system, where the indication mayinclude the address of the resource. The method/operations may alsoinclude sending an indication to the requesting system, where theindication may include an identification of the one of the plurality ofresource protection systems.

BRIEF DESCRIPTION OF THE DRAWINGS

A further understanding of the nature and advantages of the presentinvention may be realized by reference to the remaining portions of thespecification and the drawings, wherein like reference numerals are usedthroughout the several drawings to refer to similar components. In someinstances, a sub-label is associated with a reference numeral to denoteone of multiple similar components. When reference is made to areference numeral without specification to an existing sub-label, it isintended to refer to all such multiple similar components.

FIG. 1 illustrates a block diagram of a cloud system for receiving,importing, validating, and augmenting client data, according to someembodiments.

FIG. 2 illustrates a block diagram of a data center that may be used inconjunction with the cloud system, according to some embodiments.

FIG. 3 illustrates a block diagram of how the solution engine and themachine learning engine generate result sets, according to someembodiments.

FIG. 4 illustrates a block diagram of the cloud system interacting witha plurality of qualification services, according to some embodiments.

FIG. 5 illustrates an external data interface in the cloud system thatcan be used for extracting information from external data stores,according to some embodiments.

FIG. 6 illustrates a simplified block diagram of the external datainterface, according to some embodiments.

FIG. 7 illustrates a simplified architecture diagram of a resourceprotection verification server interacting with a plurality ofrequesting systems and a plurality of resource protection systems,according to some embodiments.

FIG. 8 illustrates a cloud-based architecture of a first GET command forthe verification server, according to some embodiments.

FIG. 9 illustrates a data flow diagram of how data subsets can beprovided from resource protection systems, according to someembodiments.

FIG. 10 illustrates a flowchart of a method for retrieving a data subsetand/or verifying resource protection, according to some embodiments.

FIG. 11 illustrates a block diagram of a data path for a second GETcommand for retrieving a full data set, according to some embodiments.

FIG. 12 illustrates a data flow diagram for requesting a full resourceprotection data set from a resource protection system, according to someembodiments.

FIG. 13 illustrates a simplified system diagram for sendingnotifications to the resource protection systems and/or the requestingsystems, according to some embodiments.

FIG. 14 illustrates an alternate architecture diagram of a resourceprotection verification server interacting with the plurality ofrequesting systems and the plurality of resource protection systems,according to some embodiments.

FIG. 15 illustrates an interface that may be generated on a clientdevice for requesting resource protection when it cannot be verified,according to some embodiments.

FIG. 16 illustrates a flowchart of a method for verifying resourceprotection statuses and requesting resource protection, according tosome embodiments.

FIG. 17 illustrates an interface diagram for various API calls that maybe used between the resource protection verification server and theresource protection systems.

FIG. 18 illustrates a data flow diagram that for transmissions during aresource protection request, according to some embodiments.

FIG. 19 illustrates an exemplary computer system, in which variousembodiments may be implemented.

DETAILED DESCRIPTION

Described herein is a novel server technology to facilitate verifyingthe details of a resource protection policy in real-time. A requestingsystem, such as a cloud-based system described below, can initiate aprocess that depends on the protected resource. At a first point duringthe process, the cloud-based system can pause the process and send arequest communication to a resource protection verification server(“verification server”). The verification server can then query aninternal database that stores data subsets describing resourceprotection policies implemented for various resources. For example, thecloud-based system can provide a resource address to the verificationserver, and the verification server can use the resource address toquery the subset database to retrieve information regarding the resourceprotection policy. Instead of storing the entire resource protectionpolicy, the subset database can store a subset of the protection policyinformation. Instead of querying the individual resource protectionsystems responsible for each resource, the verification server canperiodically receive a subset upload from each of the resourceprotection systems that subscribe to the verification server. Forexample, each night, the resource protection systems can upload datasubsets for each resource protection policy administered by the resourceprotection system. The subsets may include only a portion of theinformation describing the resource protection policies, and thus thesubset database can efficiently store protection policy information formillions of resources in a memory-efficient manner. Because theinformation is stored locally, the verification server can respond tothe cloud-based system after querying the subset database, and theentire transaction can be completed in real time without a significantdelay. The subset of information provided by the verification server canact as a verification that the resource protection policy is active, andthe process executing at the cloud system can be allowed to continueexecuting.

At a second point in the process, the cloud-based system can again causethe process to pause as additional details regarding the resourceprotection policy are required for continued execution. Again, thecloud-based system can send a request to the verification server toretrieve a full data set related to the resource protection policy. Insome embodiments, the full data set related to the resource protectionpolicy may be stored locally at the verification server. In someembodiments, the verification server may include a plurality of APIsthat are specially tailored for each of the external resource protectionsystems. The verification server can reach out to these APIs andretrieve full data sets of information for an existing resourceprotection policy. The verification server may include an event hub anda stream analytics module that analyze the traffic going back and forthbetween the requesting systems (e.g., the cloud-based system) and theresource protection systems. The event hub can monitor individualcommunications and send notifications to both the requesting systems andthe resource protection systems to help ensure that the resourceprotection policy under the current resource protection system continuesuninterrupted. The event hub can also generate notifications to therequesting system when a different resource protection system canprovide a better resource protection policy for a particular resource.Additionally, the event hub can monitor data as it passes through theverification server in the aggregate, such that the population ofresource protection policies can be analyzed to generate notificationsfor the resource protection systems to help improve resource protectionpolicy implementation.

Before describing the novel technology of the resource protectionverification server, this disclosure will discuss a cloud-based systemcoupled with an on-premises system, each of which can act as arequesting system for the resource verification server. The cloud-basedsystem and the on-premises system described below are provided merely byway of example and are not meant to be limiting. However, they doprovide examples of processes that may rely on resources and that mayrequire verification of an operating resource protection policyavailable through a network. FIGS. 1-6 describe such processes that mayoperate on such requesting systems. FIGS. 7-14 then describe thetechnology of the resource protection server.

FIG. 1 illustrates a block diagram of a cloud system 106 for receiving,importing, validating, and augmenting client data, according to someembodiments. The client data collection process may begin with a clientdevice 102 accessing the web server 108. The client device 102 mayinclude a laptop computer, a desktop computer, a smart phone, a PDA, atablet computer, a workstation, a voice-activated device or personalassistant, a watch, and/or the like. The client device 102 may beoperated by a user to explore various data set options that may beavailable through the cloud system 106. The client device 102 mayinclude a software application that acts as a network interfaceapplication 104 to parse and display data sent from the web server 108and send information from the user. Depending on the particular hardwareof the client device 102, the network interface application 104 mayinclude a web browser operating on a desktop computer, an app operatingon a smart phone, a voice recognition application operating on a controldevice, including the Google Home® or the Amazon Alexa®.

The client device 102 may communicate through a network, such as a localarea network (LAN), a wide-area network (WAN), the Internet, and soforth. In the embodiment of FIG. 1, the cloud system 106 may providecontent to the network interface application 104 via a content deliverynetwork (CDN) 154. The CDN may include a plurality of edge servers 150and at least one origin server 152 to store and distribute cached copiesof the website 110 provided by the web server 108. The website 110 mayinclude programming code, such as JavaScript, that provides front-endfunctionality to the website 110 when interacting with the client device102. For example, the website 110 can collect client data that may beused to generate a result set by walking the user through a series ofweb forms. The client data may include information descriptive of theuser, such as identification numbers. The website 110 can also useinformation supplied by the client device 102 to solicit informationfrom third-party services through various APIs and/or web serviceinterfaces. An example of a progression of web forms that collectinformation needed to recommend and/or approve a result set for the useris described in greater detail below. The client data may be provided inone or more data packets transmitted from the client device 102.

The CDN 154 can provide local copies of the website 110 to the clientdevice 102 from an edge server 150 that is closer in proximity to theclient device 102 than the web server 108 itself. One of the problemssolved by the embodiments described herein involves the speed with whichresult sets can be provided and updated on the display of the clientdevice 102. The architecture illustrated in FIG. 1 is specificallydesigned to increase the speed with which these results can be displayedon the client device 102 from a hardware perspective.

The website 110 is used only as an example of one of the ways that thecloud system 106 can interact with the client device 102. Therefore,this disclosure should not be limited to a website per se. Instead, theterm website 110 throughout this disclosure may be replaced with anyuser interface capable of receiving data from the client device 102 andtransmitting data to the client device. For example, another embodimentcan provide a voice activated, audio interface for communicating withclient devices through voice services such as Alexa® by Amazon®. Anotherembodiment can use an entertainment dashboard in a vehicle as aninterface for communicating with the client device 102. Similarly, theweb forms presented through the website 110 are also used as an examplethat is specific to the website 110 environment. In this disclosure, theterm web form may be replaced with any sort of digital form that canpresent and receive information to a user through the network interfaceapplication 104. For example, the form could include interactive userinterface elements displayed in an application running on a smart phoneor smart watch. In another example, the form may include audio providedto a user and audio received from a user in a voice-activated userinterface. Therefore, the terms “website” and “web form” are merelyexemplary and not meant to be limiting.

The cloud system 106 may include a load balancer 122 that receivesInternet traffic that may include client data provided from the clientdevice 102. As used herein, the term “client data” may include anyinformation received from the client device 102. For example, clientdata may include numerical values, data fields, estimates,identification numbers, addresses, user account identifiers, and soforth. As described in greater detail below, the client data receivedfrom the client device 102 may be augmented with information receivedfrom third-party web services and/or application programming interfaces(APIs). The client data may also be verified or validated usingthird-party validation interfaces that are external to the cloud system106.

The cloud system 106 may include hardware elements that may beelectrically coupled via a bus. The hardware elements may include one ormore central processing units (CPUs), one or more input devices (e.g., amouse, a keyboard, etc.), and one or more output devices (e.g., adisplay device, a printer, etc.). The cloud system 106 may also includeone or more storage devices. By way of example, storage device(s) may bedisk drives, optical storage devices, solid-state storage device such asa random access memory (“RAM”) and/or a read-only memory (“ROM”), whichcan be programmable, flash-updateable and/or the like.

The cloud system may additionally include a computer-readable storagemedia reader, a communications system (e.g., a modem, a network card(wireless or wired), an infra-red communication device, etc.), andworking memory, which may include RAM and ROM devices as describedabove. In some embodiments, the cloud system 106 may also include aprocessing acceleration unit, which can include a DSP, a special-purposeprocessor and/or the like.

The computer-readable storage media reader can further be connected to acomputer-readable storage medium, together (and, optionally, incombination with storage device(s)) comprehensively representing remote,local, fixed, and/or removable storage devices plus storage media fortemporarily and/or more permanently containing computer-readableinformation. The communications system may permit data to be exchangedwith the network and/or any other computer described below with respectto the cloud system 106.

The cloud system 106 may also comprise software elements, shown as beingcurrently located within a working memory, including an operating systemand/or other code, such as an application program (which may be a clientapplication, web browser, mid-tier application, RDBMS, etc.). It shouldbe appreciated that alternate embodiments of a cloud system 106 may havenumerous variations from that described above. For example, customizedhardware might also be used and/or particular elements might beimplemented in hardware, software (including portable software, such asapplets), or both. Further, connection to other computing devices suchas network input/output devices may be employed. Software of cloudsystem 106 may include code for implementing various embodiments asdescribed herein.

The Web server 108 may be part of a front end 156 posted by the cloudsystem 106. The front end 156 may additionally include other hardwareand/or software components that quantify the performance of the Webserver 108. Some embodiments may include a content management system(CMS) 118 to support the creation and/or modification of digital contentthat is presented by the Web server 108 to the client device 102. Someembodiments may include an analytics component 116, such as a customerexperience management (CEM) system that captures and analyzes thedetails of the experience of the user of the client device 102. Someembodiments may include a testing and targeting component 114 used totarget specific users with specific content. Some embodiments may alsoinclude a gr data analysis component 112 that searches, monitors, andanalyzes machine-generated big data via a web interface bycapturing/indexing/correlating real-time data in a searchable repositoryto generate reports, graphs, and other visualizations. These components112, 114, 116, 118 can be used by the cloud system 106 to analyze theeffectiveness of the content provided by the website 110 over time.

The cloud system 106 may also include a middleware layer 124 that actsas an interface between the front end 156 and other data systems in thecloud system 106. The middleware layer 124 may perform applicationintegration, data integration, and handle messages passed back and forthbetween the cloud system 106 and an on-premises data center 138 andother external systems. In the embodiment of FIG. 1, the middlewarelayer 124 may include an API 126 and a listener 128 for generating andreceiving responses from various systems. For example, the middlewarelayer 124 can communicate with a client data database 120 that securelystores client data received from the client device 102. The client datadatabase 120 can be used in conjunction with other off-cloud databasesto store client data between web sessions for a particular user. Themiddleware layer 124 can also interface with a request queue 132 and aresponse queue 134 of the cloud system 106. The request queue 132 canstore messages passed from the middleware layer 124 to other systemsboth inside and outside the cloud system 106. Similarly, the responsequeue 134 can receive messages passed from other systems to themiddleware layer 124.

Some of the external systems that interface with the cloud system 106may include the on-premises data center 138 and one or more Web servicesand/or APIs 140. To interface with these external systems, the cloudsystem 106 may include an API Gateway or Enterprise Service Bus (ESB) toprovide a central point for managing, monitoring, and accessing exposedWeb services. Data can be passed from the middleware layer 124 to theAPI Gateway/ESB 136 through the request queue 132 and/or the responsequeue 134. Additionally, the front end 156 may communicate directly withthe API Gateway/ESB 136.

To collect the client data from the client device 102, the website 110may present a series of dynamic web forms to the network interfaceapplication 104. Before, during, and/or after this process of collectingclient data begins, the cloud system 106 may require the user toestablish a user account with the cloud system 106. Some embodiments mayinclude an authentication module 130 that authenticates an identity of auser of the client device 102. The authentication module 130 maycommunicate with the data center 138 through the API Gateway/ESB 136.

The presentation of web forms may include a type of web form that allowsthe client device 102 to submit data provided by the user. The web formcan receive data from the user that may require some form ofverification before it is used in the selection of a data set or thegeneration of a result set. Prior to this disclosure, such dataverification could take days or even weeks to perform. This generallydiscouraged users from completing the web session and generating aclient data packet. To solve this and other problems, the embodimentsdescribed herein may use an external data interface 141 to verify theclient data provided from the client device 102. The external datainterface 141 may, for example, retrieve a history of data values fromother computer systems that can be used to generate an estimate ofcertain fields in the web form provided by the user. For example, theexternal data interface 141 may provide a verified value to the cloudsystem 106, and the data provided from the client device 102 may beverified if that data falls within a predetermined range of the verifiedvalue. This data verification step allows for greater accuracy andreliability when selecting candidate data sets and generating resultsets for the client device 102.

The external data interface 141 may also retrieve data that can be usedto supplement and/or correct information provided from the client device102. Depending on the complexity of the web session, some users may beunwilling to manually enter all of the client data requested by thewebsite 110. Other users may enter incorrect information accidentally orpurposefully. The external data interface 141 provides an alternative toprevious systems that required the user to manually provide all currentdata through the client device 102. Instead, the external data interface141 can select at least a portion of the current data provided to theweb form to automatically download a portion of the current data fromthe external data interface 141. For example, instead of manually typingcurrent data values into the web form, the cloud system 106 can insteaduse a user identifier and/or user credentials to download a portion ofthe current data automatically through the external data interface 141.This process can decrease the amount of time required for the user toprogress through the plurality of web forms, and can reduceuser-injected errors into the client data. Information may be importedfrom the external data interface 141 as data packets. The external datainterface 141 may access a third-party computer system that provides theimported data. After the client data is collected from the client device102 and optionally supplemented/verified by data from the external datainterface, the system can use the client data to generate a solutionthat includes one or more result sets.

FIG. 2 illustrates a block diagram of a data center 138 that may be usedin conjunction with the cloud system 106, according to some embodiments.In this embodiment, the cloud system 106 may be separate from the datacenter 138. For example, the data center 138 may be physically hosted byan entity that generates the result sets to the client device 102, whilethe cloud system 106 may be hosted by a cloud service provider that isdifferent from the entity providing the data center 138. However, inother embodiments, the functionality provided by the data center 138 mayalso be located in the cloud system 106. Some embodiments may duplicatethe functions described below for the data center 138 in both the cloudsystem 106 and the data center 138. Therefore, the bifurcation of thesystem between FIG. 1 and FIG. 2A is done by way of example and notmeant to be limiting. Other embodiments may divide the functionalitydescribed herein between the cloud system 106 and the data center 138 inany combination of functions without limitation. In another embodiment,the architecture of FIG. 2 may have the software/hardware componentsfrom the data center 138 instead located in the cloud system 106.

The data center may include various databases that store client data,along with systems that provide content for the cloud system 106. Togenerate solutions based on the received client data, the data center138 may include a data hub 202 that receives a packet of client datafrom the cloud system 106 and generates one or more result sets that aretransmitted back to the cloud system 106. The data hub 202 may act as acentral accumulator of the client data that finalizes the client datapacket for generating a solution. Specifically, the data hub 202 may bemade up of a plurality of processes that augment, format, filter, andprocess the client data in such a way that a solution engine 236 and amachine learning engine 238 can generate an optimal result set.

In some embodiments, the data hub 202 can augment the client data byexecuting a process 204 that requests a location code 216 from alocation service 230 through an API/web service 224. The location codemay designate a general geographic area to be associated with the clientdata. The data hub 202 may also include a process 206 that uses thelocation code retrieved from the location service 230 to retrieve rulesor penalties 218 that may be applied to the candidate data sets based onlocation. The process 206 can send the location code through an API/webservice 226 to a data service 232 specifically configured to providesuch rules or penalties 218 for candidate data sets. These may include acost that is applied to the data set based on the location from thelocation service 230. In some embodiments, a process 208 may retrieveadditional data 219 from a data service 240 through an API/web service228. The data 219 received from the data service 240 may include arating for the user that may influence which particular candidate datasets that may be available to the user. The data service 240 may includea third-party service that provides a rating for the user that is basedat least in part in some of the values provided in the client data fromthe user, as well as a previous history of the user.

After augmenting the client data, the data hub 202 can include a process210 to generate a set of filtered data. As used herein, the termfiltered data may refer to a specific subset of the augmented clientdata that is formatted for submission to the solution engine 236. Thefiltered data can be used by the solution engine 236 to filter outcandidate data sets from a collection of available data sets that arenot available to the user. For example, at this stage, the client datamay include an exhaustive list of information that may be needed laterby the system in future web sessions. However, much of the client datamay not be needed at this stage of the process for filtering thecollection of available data sets. Therefore, the process 210 can selecta subset of the information in the client data, format the filtered dataaccordingly, and send the formatted subset of the client data to thesolution engine 236. In response, the solution engine can provide aplurality of candidate data sets from the collection of available datasets for consideration by the data hub 202.

Next, the data hub 202 can select one or more optimal data sets from theplurality of candidate data sets through a process 212 that accesses amachine learning engine 238. The machine learning engine 238 can useadditional information from the filtered and/or client data. Forexample, the solution engine 236 may provide a plurality of data setsthat are available to the user based on the filtered client data. Themachine learning engine 238 can select an optimal subset of theavailable data sets to be transmitted back to the client device 102. Aprocess 214 can then rank the result sets by type and send the resultsets to the cloud system 106 for transmission to the client device 102.

The data hub 138 may govern the overall process of collecting the clientdata, determining which, if any, portions of the client data are missingor invalid, and calling upon external services to augment the clientdata with additional information. For each field in the client data, arules engine 250 can execute a validation rule to ensure that the clientdata is valid (e.g., “is the value of the rate field greater than0.00?”). The rules engine 250 can also determine which external dataservices may be used to retrieve data that is missing from the clientdata packet. For example, a rating from an external rating service maybe required before candidate data sets can be selected. If the rulesengine 250 determines that the client data set is missing this rating,it can cause the process flow of the data hub 202 to make a request tothe external rating service to retrieve a rating for the user. Overall,the rules engine 250 can orchestrate the process flow of the differentprocesses 204, 206, 208, 210, 212, 214, etc., in the data hub 202.

FIG. 3 illustrates a block diagram of how the solution engine 236 andthe machine learning engine 238 generate result sets 324, according tosome embodiments. The filtered data 313 can be passed to the solutionengine 236, and process 306 can use the filtered data 313 to generate aplurality of rules and subsequent constraints to be applied to theavailable data sets. As described in greater detail below, the process306 can use fields in the filtered data 313 to eliminate subsets of theavailable data sets, which can be expressed in constraints statements.For example, a determined data type may be used to eliminate certaindata sets from the collection of available data sets. In someembodiments, the collection of available result sets may be categorizedaccording to a type that may correspond to the data type in the filtereddata 313. One or more constraint expressions may be constructed by theprocess 306 that would eliminate available data sets associated withthat particular data type from the collection of available data sets forthis particular set of filtered data 313.

After generating the constraints, the solution engine 236 can execute aprocess 308 that applies the constraint statements to the collection ofavailable data sets. The collection of available data sets may be storedin a database 302, and may include thousands of different data setoptions. Data sets may be categorized based on a time interval, a rate,a source, and so forth. Data sets may also be categorized based oneligibility of the user based on augmented client data. In someembodiments, the constraint expressions can be applied in a single passto each individual available data set; however, other embodiments mayapply constraint expressions in multiple passes through the availabledata set. After the constraints are applied, a linear regression method310 can be used to generate a set of candidate data sets 318. Thesecandidate data sets may represent data sets for which the user may beeligible.

Next, the candidate data sets 318 can be provided to the machinelearning engine 238. The machine learning engine can analyze thecandidate data sets 318 and select one or more optimal data sets 314from the candidate data sets 308. The machine learning engine 238 canuse a collection of historical data selections 304 to determine theoptimal data set(s) 314. For example, the client data provided by theuser may be used to generate a user profile. The machine learning engine238 can compare the user profile for this particular user to userprofiles for previous web sessions associated with different users. Thedata set selections of previous users can then be used to determinewhich of the candidate data sets 318 would most likely be chosen by thecurrent user.

For example, after each web session, the machine learning engine 238 canstore the optimal data sets presented to each user, along with which ofthe optimal data sets was selected by each user in the collection ofhistorical data selections 304. Additionally, the machine learningengine 238 can store the user profile derived from the augmented clientdata for each user with the selection information. When a new pluralityof candidate data sets 318 is received for a new user, the augmentedclient data can be used to generate a similar user profile. For example,a set of values can be extracted from the augmented client data togenerate a user profile 320. The user profile 320 can be matched to oneor more historical user profiles. The final selections made by the usersassociated with the matched historical profiles can then be used toinfluence the selections made from the candidate data sets 318 for thecurrent user. For example, if a number of previous users all selectedcertain types of optimal data sets that were presented, the previouslyselected optimal data sets can be ranked higher, based on this priorselection data. In essence, the machine learning engine 238 may use theexpressed preferences of previous users to determine which of thecandidate/optimal data sets are most likely to be selected by thecurrent user.

FIG. 4 illustrates a block diagram of the cloud system 106 interactingwith a plurality of qualification services 406, according to someembodiments. After the user has finalized the result set by adjustingvalues in the result set 324 through the web interface, the finalizedresult set 412 can be sent to a universal qualification engine 404 ofthe cloud system 106. The finalized result set 412 may include finalvalues for the adjustable parameters that are set by the user, such as afinal value for a rate field, a final value for a cost or penalty field,a final value for a time interval field, and so forth. Additionally, theclient data that was collected, imported, augmented, and validatedduring the process described above may be stored in the client datadatabase 120. The client data 414 may also be provided to thequalification engine 404.

After receiving the finalized rule set 412 and the client data 414, thequalification engine 404 can filter and/or combine data fields from thefinalized result set 412 and the client data 414 to put togetherspecific data packages that are required by each of the qualificationservices 406. Each qualification service 406 may require certain datapoints from the finalized result set 412 and/or the client data 414, andthe qualification engine 404 can assemble data packages that match therequirements of each particular qualification service 406. Additionally,each qualification service 406 may require that each data packet beformatted according to specific requirements, such as a specific XMLfile format. The qualification engine 404 can format each data packageaccording to the requirements of each particular qualification service406.

Through the API Gateway/ESB 136, the qualification engine 404 can senddata packages to one or more of a plurality of qualification services406. Some qualification services 406 may be communicated with directlyby the cloud system through a corresponding public API or web serviceinterface. Secondary qualification services 408 may be accessiblethrough another qualification service 406-1. In these cases, the datapackage can be formatted and selected based on the requirements of thequalification service 406-1, and a field or designator may be providedindicating that the qualification service 406-1 should send the requestto a specific secondary qualification service, such as qualificationservice 408-2.

In some cases, each qualification service 406 may impose a penalty orcost on each submitted request. Therefore, it may be advantageous forthe cloud system 106 to intelligently determine an order of precedenceor ranking for the qualification services 406. When a plurality ofqualification services are available, the cloud system 106 can rank eachof the qualification services based on the criteria discussed below,then sequentially send requests to each of the qualification services406 until an acceptable result has been returned. In some embodiments,the request may be sent simultaneously to each of the qualificationservices 406 without regard for a specific penalty for each. Instead,the system can analyze the results from each of the qualificationservices 406 to determine which of the results is most advantageous.

FIG. 5 illustrates an external data interface 604 in the cloud system106 that can be used for extracting information from external datastores, according to some embodiments. As described above, the cloudsystem 106 may include a website 602-1. The website 602-1 can be used toinitially collect information from the client device to begin theprocess described above. However, the website 602-1 may be just one of aplurality of possible requesting systems 602. These requesting systems602 may include a client portal 602-2 allows client devices to accessand edit their data sets after the process described above in FIGS. 1-4to generate a final result set has been completed. The requestingsystems 602 may also include a partner portal 602-3 that is apartner-facing web application used to feed client data to othersystems. Some of the requesting systems 602 may be part of the samecloud system 106 as the external data interface 604. Alternatively oradditionally, some of the requesting systems 602 may be part of theon-premises data center 138, such as requesting system 602-4. In otherembodiments not explicitly shown in FIG. 5, some requesting systems 602may also reside in other computing locations.

Together, the requesting systems 602 may be referred to herein as“internal” systems, in that they are internal to the cloud system 106and/or the on-premises data center 138. This terminology can be used todifferentiate the internal systems from the “external” data stores 620that are being accessed. In some embodiments, the internal systems mayall be operated by the same entity, whereas the external data stores 620may each be operated by different entities. The internal systems alsomay be used for editing or collecting client device data from the clientdevice for the process described above in FIGS. 1-4, whereas theexternal systems are used to supplement or verify information providedby the client device.

An API interface 622 may also be provided in the cloud system 106 toboth identify and filter the requesting systems 602 (the internalsystems) making requests, and to provide a uniform interface for eachtype of call that may be made to one of the external data stores 620.The API interface 622 can whitelist and/or blacklist any systems makinga request. In some embodiments, each of the requesting systems 602 canbe included on a whitelist such that no external systems can make callsthrough the API interface 622. In some embodiments, the API interface622 can standardize the format for requests made to any external datastore 620 using, for example, a REST interface. For example, POST or GETcommands received through the API interface 622 can be used to extractdata sets for single client identifiers, as well as batches of multipledata sets for multiple client identifiers.

In other embodiments, the API interface 622 may include a specifiedformat for each subset of external data stores 620 that provide similarfunctions, provide similar services, and/or store similar data. Forexample, external data stores 620-1, 620-2 may each similarly provide acertain type of data that can be used to supplement client data in thesame way. One function of the external data interface 604 and the APIinterface 622 is to abstract the details of selecting between all of theexternal data stores 620 to find the right subset of external datastores that can service the request from the client device, as well asselecting one of the subset of external data stores that can optimallyservice the request. Therefore, the API interface 622 may includestandardized interfaces (e.g., POST/GET) for accessing similar types ofdata. When a command is received through the API interface 622, theexternal data interface 604 can determine the subset of external datastores 620 that are capable of servicing the request by virtue of thetype of call received through the API interface 622. Each call that isspecific to a subset of the external data stores may include parametersthat are needed to access the corresponding subset of external datastores 620.

As will be described below in detail, the external data interface 604can receive requests from the API interface 622 and proceed to check alocalized cache for previous results, build a full request using storedclient device data, select a single external data store from theidentified subset of external data stores, and package the request in aformat specific to the selected external data store. The cloud system106 may include a client data store 610 that includes informationreceived from the client devices, such as identification informationthat can be used to uniquely identify the user of the client device, andwhich can be used by the external data interface 604 to completeotherwise incomplete requests received through the API interface 622.The cloud system 106 may also include a database for external data 612that has been previously extracted from the external data stores 620.The database for external data 612 can be used to service requests tothe external data interface 604 without making an additional call to theexternal data stores 620 in certain situations described below.

After results are received from the external data stores 620, theexternal data interface 604 can store and analyze these data for futureprocesses. A file intake service 608 may have portions that reside bothin the cloud system 106 and in the on-premises data center 138. The fileintake service 608 can receive data and documentation from the externaldata stores 620 and encrypt and transfer them to an on premises datastore 614. The external data interface 604 can also perform certainevaluations to analyze the data received from the external data stores620. In some cases, this analysis may verify information previouslyprovided from the requesting systems 602 or augment the client data withinformation that has not yet been provided from the requesting systems602. These evaluations may interface with a workflow manager 606 to bothadd and remove tasks specific to a particular client data set.

It will be appreciated that each of the external data stores 620 mayinclude a web service interface or other standard API that includesformats or parameters that are very specific to each individual externaldata store 620. Therefore, before sending a request, the cloud system106 may need to perform extensive formatting and repackaging of arequest received through the API interface 622 before it is sent to theexternal data stores 620. One of the benefits provided by the systemdescribed herein is that the API interface 622 provides a standardizedand stable interface for each of the requesting system 602 to makerequests. As the web service interfaces of each of the external datastores 620 change over time, the external data interface 604 can bechanged centrally to match the interfaces of the external data storessuch that the requesting systems 602 are isolated from these changes.Put another way, the external data interface 604 and its surroundingAPIs abstract the details of interfacing directly with the external datastores 620 from each of the requesting systems 602. Furthermore, whenmultiple external data stores 620 offer similar services, the externaldata interface 604 can abstract the process of determining which subsetof the external data stores 620 are capable of servicing the request, aswell as selecting one of the subset of external data stores 620 forservicing a particular request.

The process of formatting and packaging a request for the external datastores can be distributed between the external data interface 604, anAPI interface/gateway 624, and an Enterprise Service Bus (ESB) 628. Theexternal data interface 604 may use a high-level programming language,such as C# or C++. Complex mappings between the data received from theAPI interface 622 and the required formats of the external data stores620 can be performed in the external data interface 604, such asinitially populating the request data fields and performing datatransformations. Other lower-level mappings can be performed in the ESB628, such as simple conversions between standardized formats (e.g., XML,and JSON). The ESB 628 can also provide a second layer of security bywhitelisting/blacklisting systems such that only the external datainterface 604 and other approved systems can make calls through the ESB628 to the external data stores 620.

Another API interface/gateway 626 can be used for synchronous calls toexternal data stores 620. For example, each external data store 620 mayhave different session characteristics, including a session timeoutinterval. For some external data stores 620-4 that require a longersession (e.g., 90 seconds) to service requests, the APIinterface/gateway 626 can handle the timing and handshakes between theexternal data store 620-4 and the cloud system 106. For example, theexternal data store 620-4 may interface with another external system andact as a middleman between the external system and the cloud system 106.This may require a longer session interval while the external data store620-4 interacts with the external system.

FIG. 6 illustrates a simplified block diagram of the external datainterface 604, according to some embodiments. After receiving therequest through the API interface 622, the external data interface 604can determine a type for the request. The type may be determined basedon a particular call made through the API interface 622. For example,functions performed by the external data interface 604 may be associatedwith particular calls through the API interface 622. The external datainterface 604 can receive a call and look up a subset of external datastores 620 that are capable of servicing the particular request type.Note that multiple calls may be made through the API interface 622 forthe same subset of external data stores 620, such as both a GET and aPOST call for a single functionality to service single and batchrequests, respectively.

After receiving the request, and before accessing any of the externaldata stores 620, the external data interface 604 can execute a localcache function 702 that checks the database of external data 612 todetermine whether the request can be serviced locally. The database ofexternal data 612 can store data previously received from the pluralityof external data stores 620. This can be useful for servicing duplicaterequests where the resulting data sets have been recently retrieved fromthe plurality of external data stores 620.

If the local cache process 702 determines that a call needs to be madeto the external data stores 620, the request can be forwarded to arequest builder 704. The request builder can determine whether theinformation provided in the request is sufficient for the selectedexternal data store to service the request. If additional information isneeded, the request builder 704 can access the client data data store610 to retrieve information that has previously been provided by theclient device. This allows the request made through the API interface622 to be fairly simple, providing, for example, only a clientidentifier when the actual requests made to the external data storesrequire a more substantial set of client data to service the request.

A source selection process 706 can take the identified subset of theplurality of external data stores 620 that are capable of servicing arequest type, and select a single external data store to service thisparticular request. A stored set of thresholds 708 that can bedynamically updated in real-time can be used by the source selectionprocess 706 to balance the manner in which requests are funneled betweenthe plurality of external data stores 620.

As described above, once a single external data store is selected, itmay require very specific formatting according to its exposed webinterface. For each of the plurality of external data stores 620, theexternal data interface may include a specific request packagingfunction 710 and external interface 712. The request packaging function710 can perform the high-level repackaging of the request received fromthe request builder 704 to match the format and data fields required bythe selected external data store. The external interface 712 can thenhandle the interaction between the external data interface 604 and theselected external data store. One advantage provided by this system isthat when the public interfaces of the external data stores change, theonly changes that need to be made to the cloud system 106 can beisolated to the request packaging functions 710 and the externalinterfaces 712. Therefore, these changes and external-system-specificdetails can be abstracted from the rest of the cloud system 106.

The external interfaces 712 can handle all of the interactions with theexternal data stores 620, including initiating a session, handling thecommunication protocol, enforcing security requirements, and monitoringthe individual timeout intervals. Each of these functions may be veryspecific to the particular external interface 712. After receiving aresulting data set from the external data stores, the request packagingfunctions 710 can translate any results received into a common formatfor the cloud system 106. Again, this ensures a stable data interfacefor any requesting system while abstracting the specific formattingdetails of the external data stores 620. The request packaging functions710 can generate a standardized response with a payload that may bespecific to each subset of external data stores (or request type). Thus,any requesting system 602 making a particular function call through theAPI interface 622 can receive a standardized response regardless ofwhich of the plurality of external data stores 620 actually services therequest.

Before being forwarded to the requesting system, the formatted responsecan be evaluated by an evaluation engine 714. For example, the datareceived from the external data store may be used to verify fieldsprovided from the client device. The evaluation engine 714 can comparefields received from the client device to corresponding fields in theformatted response to determine whether the fields received from theclient device can be verified. Some embodiments may use storedthresholds or other metrics in that comparison. For example, if a valueprovided by the client device is within 5%, 10%, 50%, 20%, etc., of thecorresponding value provided from the external data store, then thevalue in the field provided by the client device can be verified. Inanother example, a value provided from the external data stores 620 canbe analyzed without requiring comparisons to data received from theclient device. Some external data stores may provide a score or metricfor a user of the client device. This score can then be compared topredetermined score thresholds to determine whether certain actions needto be taken by the user of the client device, or whether the user of theclient device is eligible for certain workflow options. The evaluationengine 714 can use the evaluation results to interface with the workflowmanager 606. For example, if values provided from the client device canbe verified using corresponding values received from the external datastores, then certain tasks can be eliminated from a client workflow inthe workflow manager 606. Conversely, if these values cannot beverified, then the evaluation engine 714 can add tasks to the workflow,such as requiring additional and/or manual verification of these values.

Some embodiments may include a file intake service 608. The file intakeservice may include a first component 608-1 that is resident in theexternal data interface 604 and/or the cloud system 106, as well as asecond component 608-2 that is resident on the data center 138. Someexternal data stores may provide documentation that can be used later todocument and/or prove the data received from the external data stores620. These documents are generally not needed in the external datainterface 604 to service future requests, but may be required tocomplete the process described above in FIGS. 1-4, an may require securestorage. Therefore, the first component 608-1 can transfer documentsand/or data to the second component 608-2 in the data center 138 to beencrypted and securely stored. In some embodiments, the first component608-1 can generate a message that is sent to the second component 608-2indicating that new data and/or documents are available. The secondcomponent 608-2 can then pull documents and/or documents from the firstcomponent 608-1, perform any necessary document format conversion,encrypt the results, and store them securely in the on-premises datastore 614. Note that the second component 608-2 can pull documents fromthe first component 608-1 using batch requests or at a later time afterthe request is serviced. The second component 608-2 can also subscribeto messages or events produced by the first component 608-1.

The data retrieved from the external data stores 620 can then bereturned in a response having a standardized format for the request typethrough the API interface 622. In some embodiments, results of theevaluation engine 714 can also be included in the response. For example,some responses can include a flag or indication denoting whether thedata provided by the client device was verified by the data providedfrom the external data stores 620.

In the example architecture described above, the cloud system and theon-premises data center executed numerous processes for granting accessto a resource. As these processes are executing, the processes mayrequire verification that the resource is protected according to atleast a minimum standard. Prior to this disclosure, the process on therequesting system was paused, and the requesting system had to send aresource protection verification request directly to a resourceprotection system that was responsible for providing protection for theresource. However, at least two technical problems would commonly arisefrom this paradigm, each of which caused the process to runinefficiently on the hardware of the underlying requesting computersystem by requiring more processing power, more memory resources, andincreasing the latency with which communications were completed over anetwork.

First, there are hundreds or even thousands of different resourceprotection systems currently in existence, each with their owncommunication interface, resource protection policies, and latencies inresponding to a request for resource protection verification. Simplyknowing the address of the resource (or some other resource-specificdescriptor) was not sufficient to determine a particular resourceprotection system that was enforcing a resource protection policy on theparticular resource. Instead, the requesting system needed to receive amanual indication identifying a particular resource protection systemthat was enforcing a resource protection policy for the particularresource. This added a manual step to the process that increased anamount of time during which the executing process was paused. This wasalso an error-prone process, as a user could misidentify or misremembera particular resource protection system enforcing a policy for the givenresource.

The second technical problem involved the network latency required tocomplete a resource verification request. Specifically, when averification request was sent directly from the requesting system to aresource protection system, the requesting system had to wait for theresource protection system to respond. In essence, the requesting systemwas left at the mercy of the resource protection system. Many resourceprotection systems employ processes that have very slow response times,such as minutes or even hours, to process a large number of verificationrequests. While waiting for a response to the request, the requestingsystem typically pauses the ongoing process related to the resource andwaits for the verification response. Response times of more than 60seconds have been shown to occasionally cause client devices workingwith the requesting system to abort the process that was paused.Additionally, pausing these processes caused computing hardware/softwareat the requesting system to be unavailable for other similar processesthat were waiting to execute on the requesting system hardware.

The embodiments described herein solve these and other technicalproblems related to the efficiency with which a process can operate onrequesting system hardware. The operations and systems that solve theseproblems include an intermediate server that acts as a resourceprotection verification server (“verification server”). The verificationserver receives periodic uploads from each subscribing resourceprotection system. These uploads include a subset of the data stored byeach of the resource protection systems related to the individualresource protection policies being enforced. The verification serverstores these data subsets related to resource protection policies in adatabase that can be queried using a resource address. When a resourceverification request is received, the verification server does not needto know the specific resource protection system enforcing a resourceprotection policy for the given resource. Instead, the verificationserver can simply use the address of the resource to access a subset ofdata in its local database that is sufficient to verify that theresource protection policy is being enforced. This verification can becompleted in a matter of seconds rather than minutes or hours asdescribed above.

In one real-world test system, the following improvements in theoperation of a requesting process on the hardware of the requestingsystem could be observed. In one time interval, the requesting systemobserved approximately 500 processes related to resources. Each of theseprocesses required a verification of a resource protection policy, aswell as data related to the resource protection policy. Each of theseprocesses was paused while a verification request was sent directly tothe resource protection systems. On average, the delay between thesending of the request and the receipt of a verification transmissionwas approximately 3 minutes, during which time approximately 25 of theprocesses executing on the requesting system were terminated.Additionally, 15 of the verification requests were unanswered.Approximately 50 of the processes were terminated because the resourceprotection system for the particular resource was not identified or wasmisidentified for the corresponding request.

When the embodiments described herein were used such that verificationrequests could be sent to the verification server instead of toindividual resource protection systems, the average delay betweensending the request and the receipt of a verification transmission wasapproximately 15 seconds. Because of the ability to estimate a resourceprotection policy described below, none of the 500 verification requestswent unanswered. Additionally, the verification requests without a knownresource protection system that previously resulted in processtermination (or at least significant delay) were all serviced by theverification server. Therefore, the technical improvements provided bythe verification server can be summarized as follows. The requestlatency using the verification server was approximately 8% of therequest latency without using the verification server. Processtermination due to unresponsive resource protection systems and/orunknown resource protection systems was virtually eliminated. Theprocessing/memory resources at the requesting system that werepreviously unavailable as processes were paused were effectively freedto increase the number of processes that could operate on the requestingsystem per hour by approximately 300%.

FIG. 7 illustrates a simplified architecture diagram of a resourceprotection verification server 750 interacting with a plurality ofrequesting systems 106, 138, 724 and a plurality of resource protectionsystems 734, according to some embodiments. A number of differentcomputer systems 106, 138, 724, referred to herein as “requestingsystems,” can each execute multiple processes related to resources. Asthese processes are executed to grant access to resources to clientdevices, each of the requesting systems may require verification ofresource protection and/or data values related to a particular resource.Each of these requesting systems 734 can make requests to theverification server 750 to receive a verification that a resourceprotection policy is in force and/or to receive specific data valuesdescribing the resource protection policy.

The verification server 750 may include one or more web interfaces 720,722. For example, a web service interface may include one or more GETcommands that can be used by the requesting systems to requestinformation associate with specific resource protection policies. Theweb interfaces 720, 722 can accommodate many requests simultaneouslysuch that the many processes operating on the requesting systems canmake requests through the interfaces 720, 722 without significant delay.

The verification server 750 may be physically separate from any and/orall of the requesting systems 106, 138, 724. In some embodiments, theverification server 750 may be located in a separate facility that isseparated from any and/or all of the requesting systems by a distance ofat least one mile. The requesting systems may communicate with theverification server 750 over a network, such as a LAN, a WAN, theInternet, etc. The verification server 750 may be hosted in acloud-based system that is separate from the cloud system 106 describedabove. A “requesting system” to be characterized as any computer systemthat sends a request to the verification server 750. The request mayrequest a simple verification that a resource protection policy is inforce and/or may include additional information, such as particular datavalues associated with the resource protection policy.

The verification server 750 may include hardware and/or softwarecomponents that are configured to provide fast responses to resourceprotection verification requests from the requesting systems. Forexample, the verification server 750 may include a subset database 726.As will be described in detail below, the subset database 726 mayinclude subsets of data that describe resource protection policies thatare enforced by the various resource protection systems 734. Manyrequests from the requesting systems may only require an indication thata resource protection policy is currently in force as specified by oneof the resource protection systems 734. Some requests may also requireone or more data values that are associated with the current resourceprotection policy. These data values can be stored in the subsetdatabase 726 and returned in response to requests from the requestingsystems. Data values requested and retrieved from the subset database726 can be accessed through a first GET command 720 in the web interfaceof the verification server 750.

The verification server 750 may also include API interfaces that caninteract with the various external resource protection systems 734. Insome embodiments, the verification server 750 may be physically separatefrom any and/or all of the resource protection systems 734. Each of theresource protection systems 734 may also be physically separate fromeach other, such that they are operated/owned by different entitiesand/or executed on physically separate computer systems in separatefacilities that are separated by at least one mile. The resourceprotection systems 734 may communicate with the verification server 750over a network, such as a LAN, a WAN, the Internet, etc. As will bedescribed in detail below, the resource protection server 734 canperiodically provide uploads of data subsets to the verification server750. These uploads can be used to populate the subset database 726 withinformation regarding resource protection policies that can be indexedby a resource address or other identifier. When requests are receivedfrom one or more of the requesting systems, the resource address orother identifier can be used to index the subset database 726 andretrieve the requested information without needing to contact theparticular resource protection system 734-1 providing the information. A“resource protection system” may be characterized as any computer systemthat administers resource protection policies for resources. Theresource protection system may provide a set of data values and/or asubset of data values that are descriptive of different aspects of theresource protection policy. In some embodiments, the APIs that allow forcommunication between the verification server 750 and the resourceprotection systems 734 may be standardized in the functionality of theAPI may be implemented by the resource protection systems 734themselves.

A second GET command 722 command can be available in the web interfaceof the verification server 750. The second GET command 722 can be usedto retrieve a full set of information regarding a resource protectionpolicy. In some embodiments, the verification server 750 can store fullversions of the resource protection policy locally at the verificationserver 750. Alternatively, the verification server 750 can then act asan arbitrator between the requesting systems and the various resourceprotection systems 734 to retrieve the full set of information from thecorresponding resource protection system. The full set of informationdescribing the resource protection policy can include many data fieldsthat are not included in the subset of data stored at the subsetdatabase 726.

As information is passed back and forth through the verification server750, an event hub 730 and a stream analytics module 732 can analyze thedata in real time and provide notifications to the requesting systemsand/or the resource protection systems based on the data traffic. Aswill be described in greater detail below, the event hub 730 can triggeron data as it flows through the system, analyze the data, and takecertain actions, such as sending notifications to one or more systems.The stream analytics module 732 can analyze the data and generatesummary information, such as heat maps and other statisticalrepresentations of the data that are useful for both the requestingsystems and the resource protection systems 734.

FIG. 8 illustrates a cloud-based architecture of a first GET command 720for the verification server 750, according to some embodiments. Asdescribed above, the two different GET commands that are exposed by theweb service of the verification server 750 can return different types ofinformation. The first GET command 720 can be used to retrieve a subsetof data values that are related to a specific resource and itsprotection. The body of the request sent through the first GET command720 may include at least an address or other identifier for theresource. In some embodiments, the payload of the response to therequest generated by the verification server 750 may include arelatively small number of data fields compared to a full resourceprotection data set. This subset of data may include an identificationof the resource protection system associated with the resource, a timeinterval during which the protection policy is in force, and a numericalvalue that is used by the paused process on the requesting system.

Prior to this disclosure, requesting systems had to contact theindividual resource protection systems. This meant that the requestingsystems had to know the identity of the resource protection system thatwas associated with the resource. Because there are thousands ofresource protection systems, some of which are confusingly similar inname and/or function, it was common for mistakes to be made such thatthe correct resource protection system was not properly identified bythe requesting system. The verification server 750 solves this problemby collecting the data subsets from each of the resource protectionsystems and indexing them in the subset database 726. Thus, the firstGET command 720 only requires the requesting system to properly identifythe resource, and that information can be extracted from the first GETcommand 720 to index the subset database 726 to retrieve the identity ofthe corresponding resource protection system.

In the embodiment depicted in FIG. 8, the verification server 750 can beimplemented in a cloud-based architecture or environment. The first GETcommand 720 can be received by a RESTful API Application Service 804available in a cloud environment, such as the Microsoft Azure® cloudenvironment. The API Application Service 804 may include an applicationservice that can be used to build API applications to handle incomingrequests. The API Application Service 804 can pass the request to acloud search module 806 that is coupled to the subset database 726. Thecloud search module 806 can generate indices and search the subsetdatabase 726 using the resource address/identifier received in the firstGET command 720. The subset database 726 may be implemented with anycloud database system, such as the Cosmos® NoSQL database.

As described briefly above, the verification server 750 may also receiveperiodic uploads from the resource protection systems 734. When aresource protection system 734 registers with the verification server750, APIs at the resource protection systems 734 and/or at theverification server 750 can be used to handle these uploads. Forexample, every 24 hours (e.g., each night), each of the resourceprotection systems 734 can upload a complete collection of data subsetsfor each resource protected by the respective resource protectionsystems 734.

The verification server 750 can receive these periodic uploads throughthe use of an FTP server. The cloud environment can include a virtualmachine (VM) 810 that hosts an FTP server. The FTP server may includetransport layer security (TLS) and/or secure sockets layer (SSL)encryption to protect information provided to the verification server750. A data factory 808 may be included to accelerate data integrationwith native data connectors. Specifically, the data factory 808 may beconfigured to provide a variety of services, such as transformations,translations, filtering, etc., to standardize the format of theinformation provided by the resource protection systems 734. In someembodiments, the VM 810 hosting the FTP fileshare can provide uploadeddata subsets to the data factory such that they can be formatted andconsumed by the subset database 726. Some embodiments may also include ablob storage 812 configured to store objects as unstructured data.Specifically, the blob storage 812 may store files received from theresource protection systems that can receive secure transfers from theresource protection systems before being ingested into the subsetdatabase 726.

The specific cloud architecture illustrated in FIG. 8 is provided merelyas one example of how the systems and methods described herein can beimplemented as a verification server 750. Other embodiments can usedifferent hardware and/or software combinations to achieve similarfunctions with varying levels of efficiency. For example, anotherembodiment may use a cloud-based environment that is shared with thecloud system 106 described above. Another embodiment may share hardwarewith the on-premises data center 138. Other embodiments may use customhardware/software that is completely separate from any of the systemsdescribed above. Therefore, the particular arrangement ofhardware/software in FIG. 8 is not meant to be limiting.

FIG. 9 illustrates a data flow diagram of how data subsets 906 can beprovided from resource protection systems 734, according to someembodiments. A full resource protection data set may include 30-50distinct data values that are descriptive of, or define a singleresource protection policy. However, it has been discovered that many ofthe processes executing on the requesting systems can resume afterreceiving only one or two values from the full resource protection dataset. Therefore, the verification server 750 can optimize its internalmemory usage by only storing data subsets. The data subsets may bedistinguished from the full resource protection data sets by includingonly information required for the processes executing on the requestingsystems to continue. For example, the data subsets in some embodimentsmay include a resource address or other identifier that uniquelyidentifies the resource; an indication of a protection interval, such asa date/time through which the resource protection policy will be validor in force; and/or one or more numerical values that characterize theresource protection policy. Some embodiments may also store anidentifier for the particular resource protection system 734-1associated with the resource. Prior to this disclosure, this indicationof a corresponding resource protection system needed to be provided withthe request rather than returned with the response. By limiting theamount of information stored at the verification server 750, the memoryusage of the verification server 750 can be optimized such that totalmemory usage can be reduced by more than 90% by storing a collection ofdata subsets when compared to storing corresponding full resourceprotection data sets for each cataloged resource.

Periodically, the verification server 750 can receive collections ofdata subsets 906 from the resource protection servers 734. In someembodiments, the resource protection servers 734 can provide a fullcatalog of data subsets 906 for each resource registered with thecorresponding resource protection server. In other embodiments, theresource protection servers 734 can instead provide a list ofchanges/updates to the verification server 750 such that only changeddata subsets are uploaded each night. In some embodiments, the resourceprotection systems 734 can initiate the uploads to the verificationserver 750. In other embodiments, the verification server 750 canalternatively and/or additionally send a request to each registeredresource protection system 734 to request an upload of the data subsets906.

When the data subsets 906 are received by the verification server 750,the software components described above in FIG. 8 can standardize theformat of the data received from each of the resource protection systems734. Each resource protection system can provide different data valuesand use different data formats. In some embodiments, the resourceprotection systems may transmit full resource protection data sets tothe verification server 750, and the verification server 750 can filterout the data values that are not necessary to respond to the first GETcommand 902 described above. The data factory described above may use astandardized format such that each of the data subsets stored in thesubset database 704 are identical in format.

When the subset database 704 receives the data subsets 906, the subsetdatabase 704 can store the data subsets 906 without basing the storageorganization on the respective source data protection system from whichthey were received. Therefore, data subsets 906 from each of theresource protection systems 734 can be stored together without beingpartitioned into separate databases based on source. Instead, the subsetdatabase 704 can store the data subsets 906 such that they can beindexed based on the address/identifier for the resource.

The request through the first GET command 902 only needs to include theaddress/identifier 904 for the resource in order to submit a validrequest. The verification server 750 can parse the GET command andextract the address/identifier 904. The address/identifier 904 can thenbe provided to the database search module 806 described above toretrieve the corresponding data subset 908 from the subset database 704.The requested data subset 908 can provide numerical values that may berequired by the paused process on the requesting system. The requesteddata subset 908 may also act as a verification that a resourceprotection policy is active and valid.

FIG. 10 illustrates a flowchart 1000 of a method for retrieving a datasubset and/or verifying resource protection, according to someembodiments. The requesting system may execute a process locally on thecomputer system, such as a cloud system, an on-premises data center,etc. The process may be associated with a particular resource, and theprocess may require information regarding the protection of the resourcebefore the process can continue. For example, the process may require averification that the resource is protected. The process may require oneor more data values that describe an aspect of the protection of theresource. The process may require an indication of a resource protectionsystem that is responsible for the resource protection. The process mayrequire a protection interval during which a resource protection policyis valid. When the process requires this information, the process maypause (1002) until such information is received. When pausing theprocess, the requesting system can send a request forverification/information regarding resource protection to theverification server (1004).

In an independent, parallel thread, the resource protection systems canprovide periodic uploads of data subsets regarding data protectionpolicies to the verification server (1008). These uploads can be storedin a subset database that is searchable by an identifier/address of eachresource. The data subsets from many different resource protectionsystems can be stored together in the subset database. When the requestfrom the requesting system is received by the verification server, theverification server can determine whether subset database stores a datasubset that corresponds to the resource address/identifier (1010). Ifthe requested data subset has been uploaded to the verification serverfrom the resource protection system(s), then the verification server canretrieve the subset fields from the database (1014) by virtue of theidentifier/address of the resource. The fields from the data subset mayinclude an indication of a particular resource protection system thatsourced the information (1016). The fields from the subset database canthen be returned to the requesting system (1018). When these data fieldsand/or a verification that the resource is protected are received by therequesting system, the requesting system can restart the paused processusing the data provided by the verification server (1020).

In some embodiments, the verification server can handle situations wherea resource is either unprotected or situations where a correspondingresource protection system has not yet uploaded a data subsetcorresponding to the resource. The process may also include determiningthat a corresponding subset is not stored in the subset database by theverification server (1010). A data subset might not be stored in thesubset database for a number of different reasons. In some instances,the particular resource protection system associated with the resourcemay not yet subscribe to the verification server. Thus, the verificationserver would not receive periodic uploads of data subsets from theunsubscribed resource protection systems. In other instances, theresource may not be protected by a resource protection system at all.

In cases where a data subset is not available from the verificationserver, the method may include estimating some of the data fields thatwould likely be part of the data subset (1012). The estimation processcan use a number of different methods to estimate these data values. Insome embodiments, the process may look up similar resources in thesubset database and average the values for the similar resources togenerate an estimated data value for the current resource. For example,resources having addresses that are numerically close to the currentresource may be retrieved, and their data values may be averaged togenerate estimated data values for the current resource. In anotherexample, resources having characteristics similar to the currentresource may be retrieved and have their data values averaged. In someembodiments, the process may submit the address/identifier for theresource to one or more of the resource protection systems. The resourceprotection systems can then generate estimated data values for thecurrent resource that would be used if the resource protection systemswere to provide a resource protection policy for the current resource.

When data values are estimated, the method can determine a particularresource protection system that can be used to protect the resource. Insome embodiments, when estimated data values are received from one ormore resource protection systems, the method can compare the estimatedvalues and select a resource protection system that generated the mostefficient values. In some embodiments, the verification server maymaintain a list of preferred resource protection systems and submit themost preferred resource protection system providing estimated datavalues as a recommendation to the requesting system (1016).

The method described above is useful for retrieving data subsets relatedto a resource protection policy. However, the processes operating on arequesting system may later be paused a second time in order to retrievethe full data set related to the resource protection policy. FIG. 11illustrates a block diagram of a data path for a second GET command 722for retrieving a full data set, according to some embodiments. Thearchitecture may receive a GET command at an API management service1104. The API management service 1104 may be comprised of a module thatorganizes the various APIs in the verification server 750 and routesdata accordingly. The verification server 750 may also use acontainerized environment, and may therefore include a containerregistry 1108 that tracks and organizes the different containerizedsoftware functions in the verification server 750.

The API management service may include an API management policy module1112 to manage access restrictions, control flow, authentication,caching, data transformation, and other routing mechanisms for parsingthe GET command received from the requesting system and preparing therequest for one or more resource protection systems. Each of theresource protection systems may include a specific API that is tailoredto handle the specific data formats, communication handshakes, andsession protocols for each particular resource protection system. Eachresource protection system may be paired with a Logic App 1114, 1122,1118, additional API App Services 1120, and one or more function modules1116 to generate POST commands for external RESTful APIs. The data pathfor some resource protection systems may include a Service FabricCluster 1124, 1126, and some may use various WebAPI interfaces, such asa REST API.NET WebAPI 1128, 1132 and/or a SOAP 1.2 Service 1130, whichmay be organized in multiple-node clusters.

The architecture illustrated in FIG. 11 is specific to a particularcloud infrastructure and is not meant to be limiting. As describedabove, the verification server 750 may be implemented on any cloudplatform or on-premises data center without limitation.

FIG. 12 illustrates a data flow diagram for requesting a full resourceprotection data set from a resource protection system 734-1, accordingto some embodiments. The second GET command 722 can send a resourceaddress 904 to the verification server 750. As described above, varioussoftware/hardware components in the verification server 750 can extractthe resource address 904 from the request and send it to the APImanagement service 1110. The API management service 1110 can post arequest to a specific resource protection system 734-1 and retrieve afull resource protection data set 1202. The full resource protectiondata set 1202 may include all the information in the data subsets asdescribed above, along with additional data values that describe aresource protection policy that is administered by the resourceprotection system 734-1. However, in some embodiments, the term “fullresource protection data set” may not imply that all information storedat the resource protection systems are sent to the verification server.Instead, the full resource protection data set may simply include asubset of the data stored at the resource protection servers that isgreater than the subset periodically uploaded to the verificationserver.

The verification server 750 can handle requests from various requestingsystems and channel them to the appropriate resource protection systems734. By acting as an intermediary, the verification server 750 canmanage the different communication protocols with each of the resourceprotection systems 734. Instead of duplicating the APIs in theverification server 750 at each of the requesting systems, only a singleserver with those APIs needs to exist at the verification server 750.This effectively reduces the amount of processing and memory usagerequired by each of the requesting systems when this functionality isconsolidated at the verification server 750.

In some embodiments, the API management service 1110 can manage a localdata store that stores the full resource protection data sets as theyare retrieved from the resource protection systems 734. If a request isreceived for a full resource protection data set that has previouslybeen requested, the API management service 1110 can retrieve thepreviously stored full resource protection data set from the local datastore and respond to the request without waiting for the delay thatwould otherwise be experienced by sending the request to the resourceprotection systems 734.

FIG. 13 illustrates a simplified system diagram for sendingnotifications to the resource protection systems 734 and/or therequesting systems, according to some embodiments. As described above,the verification server 750 may include an event hub 730 that triggerson certain data fields and/or conditions as they pass through the APImanagement service 1110. As the full resource protection data sets passthrough the API management service 1110, the event hub 730 can parse the25-30 data fields in each full data set and capture specific values thatcan be compared to thresholds and other conditions to generate eventsand/or notifications. The notifications 1302, 1306 generated from theevent hub 730 may be related to the specific resource protection dataset passing through the API management service 1110.

In some embodiments, a notification 1302 may be sent to one or moreresource protection systems 734. For example, some requests may indicatethat the resource owner may be changing via the process executing at therequesting system. In the past, when resource ownership changed, theresource protection system providing a resource protection policy to theresource was likely to change as well. Because the verification server750 is used as an intermediary to process these requests, it candetermine by virtue of the request type that certain types of requestsindicate a likelihood of a change in ownership of the resource. Inresponse, the event hub 730 can send a notification 1302 to the resourceprotection system 734-1 currently protecting the resource. This mayallow the resource protection system 734-1 to reach out independently tothe new owner of the resource to continue to provide the resourceprotection policy for the resource.

In some embodiments, a notification 1306 may also be sent to therequesting system. For example, the event hub 730 can send anotification 1306 indicating a current resource protection system 734-1administering a resource protection policy for the resource. This may beused by the owner of the resource to determine whether or not theresource protection policy provided by the resource protection system734-1 should stay in force, or whether the resource owner should chooseto select a new resource protection system. Additionally, someembodiments may allow the requesting system to directly make changes tothe resource protection policy implement by the resource protectionsystem. This option may be made available for currently subscribed orpartnered resource protection systems. For example, the requestingsystem may change options in the resource protection policy, changevalues and/or validity dates associated with the resource protectionpolicy, and/or make any other changes to how the resource is protected.Changes from the requesting system can generate automated actions thatare passed on to the resource protection systems through theverification server.

In addition to analyzing individual communications by the event hub 730,the verification server 750 can also use the stream analytics module 732to analyze a history of resource protection data sets as they passthrough the API management service 1110. The stream analytics module 732can identify trends, statistical outliers, and other information thatcan be useful to the resource protection systems and/or the requestingsystems. The stream analytics module 732 can extract individual datafields from each resource protection data set and internally storeaverages, histograms, and/or other statistical characterizations of thepopulation of resource protection data sets.

In some embodiments, the stream analytics module 732 can provide anotification 1304 to the resource protection system 734-1. The streamanalytics module 732 can store and analyze data values from the fullresource protection data sets as they pass through the verificationserver 750. From these data values, the stream analytics module 732 cangenerate statistical information that is descriptive of the populationof full resource protection data sets uploaded to the verificationserver 750. Individual values that are passed through the API managementservice 1110 can be compared to a history, average, or other statisticalcharacterization of the population of full resource protection data setsto provide feedback to the resource protection systems 734 and/orrequesting systems to optimize the match between a particular resourceand a resource protection system.

In some embodiments, the stream analytics module 732 can generate anotification 1304 that compares data values in a current full resourceprotection data set to average data values for similar resources thathave been seen in the past by the API management service 1110. Forexample, if a current data value from a resource protection system 734-1is significantly higher/lower than a corresponding data value receivedfrom other resource protection systems for similar resources, thenotification 1304 can be sent to alert the resource protection system734-1 that its data value is significantly higher/lower than otherresource protection systems.

In some embodiments, the notification 1304 generated by the streamanalytics module 732 may include heat maps or other statisticalcharacterizations of the population of data sets. These can be used bythe resource protection systems 734 to identify groups of resources(e.g., resource address ranges, resource types, resources of certainsizes, etc.) that are either overserved or underserved by a particularresource protection system. This information can be used by the resourceprotection systems to contact resource owners and to identify ways thatthe resources can be protected by the resource protection systems.

In some embodiments, the stream analytics module 732 can also send anotification 1308 to the requesting system. The notification 1308 cangenerate a comparison of different data values associated with differentresource protection systems. These data values can be used as acomparison to evaluate a current data value for a resource protectionpolicy being enforced by a current resource protection system 734-1.Some embodiments may also send recommendations of resource protectionsystems to the requesting system. These recommendations may be based ona comparison of data values, and/or a prioritized list of preferredresource protection systems maintained by the verification server 750.

FIG. 14 illustrates an alternate architecture diagram of a resourceprotection verification server 750 interacting with the plurality ofrequesting systems 106, 138, 724 and the plurality of resourceprotection systems 734, according to some embodiments. This alternatearchitecture is similar to the architecture illustrated in FIG. 7.However, in contrast to FIG. 7, this alternate architecture eliminatesthe need to store any personal identifying information from any of therequesting systems at the resource protection verification server 750.Instead of receiving periodic uploads of information from the resourceprotection systems 734, the resource protection verification server 750can act as an intermediate server to service requests between thevarious requesting systems 106, 138, 724 and the resource protectionsystems 734 in real time. This eliminates the overhead that can beassociated with storing personal information for users of the requestingsystems. This also eliminates the need to store any data subsetsdescribing resource protection statuses at the resource protectionverification server 750. Instead, the resource protection verificationserver 750 can translate single requests from the requesting systems tosimultaneously or serially check for resource protection at any numberof resource protection systems 734.

For example, when an initial request to verify resource protection isreceived through the web interface 720, the API management service 728can receive the request from the requesting system. As described above,the request may include identifying information for a user associatedwith the requesting system, as well as an address for the resource inquestion. In a general sense, any of the requesting systems 106, 138,724 may be simply referred to as “client devices” in this disclosure.The API management service 728 can receive, for example, a singlerequest or multiple requests from the cloud system 106 to verifyresource protection of one or more particular resources.

The API management service 728 may next identify the resource protectionsystems 734 that are in communication with the resource protectionverification server 720 and available for servicing requests. Althoughthe resource protection systems 734 need not provide periodic uploads ofdata subsets to the resource protection verification server 750, theresource protection systems 734 may still register, subscribe, orotherwise partner with the resource protection verification server 750.This allows the resource protection verification server 750 to maintaina list of approved, subscribed, or otherwise available resourceprotection systems 734. Alternatively, the API management service 728may discover available resource protection systems 734 and dynamicallyremove or add them to a list of available resource protection systemssuch that the resource protection verification server 750 provides themost up-to-date listing of available resource protection services forrequesting client devices. Some embodiments may alternatively oradditionally receive approved lists of resource protection systems froman administrator and/or from an external service.

After determining a plurality of resource protection systems 734 thatare available, the API management service 728 may further identify asubset of the resource protection systems 734 that should be queried toservice the current request. The resource protection verification server750 may use attributes of the current request to select the subset ofthe resource protection systems 734 to service that request. Forexample, the API management service 728 may select a subset of resourceprotection systems 734 that can be associated with an address of theresource. The API management service 728 may maintain or receive addressranges that can be used to match resource addresses with availableresource protection systems. For example, an address within a particularaddress range may be associated with a subset of resource protectionsystems known to be available in that address range.

In some embodiments, the subset of available resource protection systems734 may be identified using a load-balancing system such that outgoingrequests may be predictably distributed between the resource protectionsystems 734. This may be useful to ensure that hundreds of requests canbe serviced by the resource protection verification server 750 withoutoverloading any single resource protection system. The load-balancingsystem may use a round-robin algorithm to distribute requests to theresource protection systems. Other embodiments may choose resourceprotection systems that are known to provide resource protection for thegreatest number of resources to be tried first, followed by smallerresource protection systems that are less likely to provide resourceprotection for some resources.

The API management service 728 may then format or reformat the requestsuch that it complies with an expected format for each of the subset ofselected resource protection systems. Some resource protection systemsmay comply with a predetermined API format. For example, the resourceprotection verification server 750 may publish or otherwise makeavailable an API format that may be expected to be used withparticipating resource protection systems 734. The API managementservice 728 can identify all such resource protection systems in theselected subset and format a single request that can be sent to eachcomplaint API interface. In some cases, resource protection systems mayalready have an established API interface that does not comply with thestandard API requested by the resource protection verification server750. In these cases, a custom code module may be implemented in the APImanagement service 728 that translates the format of the request into anexpected format for each custom API as required. These formattranslations may depend primarily on the expected format of thepublished API of the resource protection system.

The API management service 728 can then send requests serially or inparallel to the subset of resource protection systems 734 to service therequest. Although the response latency of each particular resourceprotection system may vary, the API management service 728 can beginevaluating responses as soon as they are received. For example, the APImanagement service 728 may begin receiving responses from the resourceprotection systems indicating whether or not the identified resource inthe request is protected by these resource protection systems. As soonas an affirmative response is received by the API management service728, it can transmit that response back to the requesting client system.Some embodiments may continue receiving responses from the resourceprotection systems to identify additional positive responses. Theseadditional positive responses can then be transmitted back to therequesting client device as they are received or together in a singleresponse. This covers cases where a selected resource is protected by aplurality of different resource protection systems. Additionally, ifnone of the responses are affirmative, the API management service 728may query additional resource protection systems until the list ofavailable resource protection systems 734 is exhausted and/or anaffirmative response is found.

The operations described above in relation to FIG. 13 may continue to becarried out by the event hub 730 and/or the stream analytics 732.Additionally, these systems may also provide additional services thatare related to the resource protection verification request. Asdescribed above, some instances may occur where the resource identifiedin the request is not protected by any of the resource protectionsystems 734. The resource protection verification request is often partof a larger data transaction that requires resource protection to beverified for the resource. For example, certain processes may not beallowed to proceed unless resource protection is verified. In caseswhere resource protection cannot be verified, the data transaction maybe allowed to continue if resource protection can be established. Theevent hub 730 and/or stream analytics 732 may aid in this process.

In some embodiments, the API management service 728 may send a responseto the requesting client device indicating that no resource protectioncould be verified. This response may also include an option to requestresource protection. FIG. 15 illustrates an interface 1500 that may begenerated on the client device for requesting resource protection whenit cannot be verified, according to some embodiments. In someembodiments, the interface 1500 can be provided by the resourceprotection verification server 750 for display on the client device,such as a webpage displayed on a client web browser. The interface 1500may include a listing of identifiers 1502 for the resource protectionsystems 734 and/or additional values 1504 associated with each resourceprotection system.

In this embodiment, the listing of identifiers 1502 may include serveraddresses for each of the recommended resource protection systems 734.In other embodiments, other identifiers may be used. For example, someembodiments may use a trademark or tradename for a company operating theresource protection system. The additional values 1504 may include anymethod of distinguishing between resource protection systems. This mayinclude a rating, a cost, a protection time interval, details thatdescribe the protection provided by the resource protection system, andso forth. These additional values 1504 may be displayed next to theidentifiers 1502 such that they can be visibly compared by a user of theclient device. In this example, only a single additional value isdisplayed in the listing of additional values 1504. This is illustratedmerely by way of example, and is not meant to be limiting. Otherembodiments may list a plurality of such additional values 1504 inadditional columns for each of the identifiers 1502.

In some embodiments, the API management service 728 can rank resourceprotection systems according to a predetermined priority listing. Forexample, a first resource protection system 734-1 may fulfill certaincriteria established by the resource protection verification server 750and thus be assigned a high priority listing. This criteria may includefactors such as a protection rating, a protection effectiveness, userratings, an availability rating, compliance with a standard API format,latency or response time, cost to the client device and/or the resourceprotection verification server 750, and so forth. In some embodiments,the criteria may include a subscription or membership level at which theparticular resource protection systems are associated with the resourceprotection verification server 750.

Note that the way resource protection systems are ranked by the resourceprotection verification server 750 can be configured to ensure fairnessto each of the resource protection systems and to the users of theclient devices. For example, the resource protection verification server750 can be configured to rank resource protection systems without regardto any benefit received by the resource protection verification server750, such as payments, number of transactions, number of resourcesprotected, or other benefits provided by the resource protectionsystems. Thus, the ranking system described above is completely optionaland not be implemented in some embodiments according to agreementsbetween the resource protection verification server 750 and the resourceprotection systems.

The list of identifiers 1502 for the resource protection verificationsystems in the interface 1500 of FIG. 15 may be displayed according tothe ranking system described above. For example, resource protectionsystems that are ranked highly may be displayed first in the list ofidentifiers 1502. Other visual indications may be applied to the list ofidentifiers 1502 to indicate the ranking or preference of certainresource protection systems. For example, additional graphics, such asstars or highlights, may be added to preferred resource protectionsystems. As illustrated in FIG. 15, resource protection systems near thetop of the list may be presented in bold, underline, or varying colorsto emphasize their display. Some embodiments may display additionalinformation for highly ranked resource protection systems.

In some embodiments, the interface 1500 may also be provided in caseswhere protection is found, if the existing resource protection isdetermined to be better performed by other resource protection systems.For example, if the protection provided by a current resource protectionsystem is found to be more costly or less effective than a resourceprotection protocol that could be provided by other resource protectionsystems, the resource protection verification server 750 can provide anindication that resource protection was verified along with a version ofinterface 1500 that allows the user to be presented with alternativeoptions for resource protection.

The interface 1500 may allow the user to select one of the presentedidentifiers 1502 and thereby proceed to submit a request to theassociated resource protection system for resource protection. FIG. 16illustrates a flowchart of a method for verifying resource protectionstatuses and requesting resource protection, according to someembodiments. The method may include receiving a request for verificationof resource protection from a client device for an address-basedresource (1602). The request may include an address of the resource. Therequest may be received by an intermediate system that is programmed toreceive resource protection verification requests for a plurality ofclient devices. The intermediate system may include the resourceprotection verification server described above. The intermediate systemmay act as an intermediary to decouple requests from client devices fromrequests sent to the plurality of resource protection systems, therebyacting as a “clearinghouse” or middleman between the client devices andthe resource protection systems. The resource protection systems mayinclude web services or servers associated with homeowners insurancecompanies.

The method may also include determining that none of the resourceprotection systems in the plurality resource protection systemscurrently protect the resource (1604). In some embodiments, this mayinclude accessing a database of data subsets that have been periodicallyprovided by the resource protection systems without making anyadditional requests to the resource protection systems. In otherembodiments, this may include sending requests to one or more resourceprotection systems to determine whether any of the resource protectionsystems provide resource protection. If no affirmative responses arereceived from the resource protection systems, or no data subset isavailable in the database, then an indication may be sent to the clientdevice indicating that the resource is currently unprotected. In someembodiments, an indication may then be received back from the clientdevice that protection for the resource should be requested. Asdescribed above, the indication that the client device is currentlyunprotected may include a list of one or more resource protectionsystems that are eligible to provide resource protection, and the listmay be organized or presented according to a priority level for eachresource protection system. The priority level may be determined basedon the factors described above, such as a preference indicated by theuser (e.g., cost, effectiveness rating, and so forth).

The method may also include retrieving information that is securelystored by the intermediate system for the resource and/or a userassociated with the request (1606). This information may include auser's name, home address, mailing address, credit information, incomeand/or asset information, personal identifiers such as a birthdate andSocial Security number, and other information that would be used in anapplication to provide resource protection. This information may alsoinclude information about the resource, such as a physical address, andcharacteristics resource, such as square footage, cost, value, age, andso forth. In a general sense, this information may include anyinformation that is descriptive of a user and/or the resource.

This information may be stored separately from the intermediate system.For example, referring back to FIG. 14, the cloud system 106 may beassociated with another data transaction involving the user. This datatransaction may include aggregating, collecting, storing, and/orverifying information regarding the user and/or the resource. Theintermediate system can leverage this information provided by the cloudsystem 106 to automatically populate fields in a request to provideresource protection from one or more resource protection systems 734.For example, the resource protection systems may provide a web serviceinput or web form input that can receive user and/or resourceinformation as an online request for resource protection. Theintermediate system in these embodiments can simplify this process forthe user by automatically importing this information from the cloudsystem 106 and using that information to automatically populate the webform or web service request to be sent to the resource protectionsystem(s) 734. Thus, the method may also include sending the informationfor the resource and/or user to one or more of the plurality of resourceprotection systems as a request to protect the resource (1608).

It should be appreciated that the specific steps illustrated in FIG. 16provide particular methods of verifying resource protection according tovarious embodiments. Other sequences of steps may also be performedaccording to alternative embodiments. For example, alternativeembodiments of the present invention may perform the steps outlinedabove in a different order. Moreover, the individual steps illustratedin FIG. 16 may include multiple sub-steps that may be performed invarious sequences as appropriate to the individual step. Furthermore,additional steps may be added or removed depending on the particularapplications. One of ordinary skill in the art would recognize manyvariations, modifications, and alternatives.

FIG. 17 illustrates an interface diagram for various API calls that maybe used between the resource protection verification server 750 and theresource protection systems 734. As described above, the transactionsfor verifying and requesting resource protection may be part of a largerset of data transactions that can each be carried out through specificAPI calls to the resource protection system 734-1. A first API 1702 canbe used to verify resource protection. The first API 1702 may receive auser name and/or an address for the resource and return an indication ofwhether resource protection is currently in force, as well as aprotection start date, protection interval, and other values associatedwith the resource protection.

A second API 1704 can be used to receive a full set of resourceprotection data. The resource protection server 750 can provide a username and an address, as well as an address for the resource. In someembodiments, the second API 1704 may also receive an identificationnumber for the resource protection file. In response, the second API1704 may return a full, complete, and/or extensive data set thatdescribes the entirety of the resource protection protocol assigned tothat particular resource. This data set may be formatted as an XML file,PDF file, a JSON object, and/or the like.

A third API 1706 may be used to request user interface information fromthe resource protection system 734-1. As described above, the resourceprotection verification server 750 may provide a user interface to theclient device that displays a list of resource protection systems, aswell as an option to request resource protection from a particularsystem. Each system may provide unique user interface information to bedisplayed as part of the user interface presented to the user. Forexample, some embodiments may receive a text string from the resourceprotection system 734-1 that should be displayed next to a tradename ofthe resource protection system 734-1 in the user interface for the user.This allows the resource protection system 734-1 to customize itsmessage for the user. The text string may include information regardinglength, cost, and other options available for the resource protectionoffered by the resource protection system 734-1.

The third API 1706 may receive a plurality of data points from theresource protection verification server 750 before providing the userinterface information. For example, the third API 1706 may receive atype of resource protection protocol being requested, as well aslocation codes. This information allows the resource protection system734-1 to determine whether resource protection can be provided in therequested location and consistent with the resource protection protocoltype being requested before providing a response. This also allows theresource protection system 734-1 to tailor and otherwise customize anyuser interface information that will be displayed to the user.

A fourth API 1708 may be used to submit a formal request for resourceprotection to the resource protection system 734-1. The resourceprotection verification server 750 can submit an extensive set of userdata and information descriptive of the resource to the resourceprotection system 734-1 as described below, this information may bereceived from the user or extracted from a secure data store and/orother third-party verification services. This information may beretrieved automatically without requiring responsive user inputs. Theresource protection system 734-1 can then return a customized URL thatcan be used to complete the resource protection request.

FIG. 18 illustrates a data flow diagram that for transmissions during aresource protection request, according to some embodiments. Thesetransmissions may take place after it is determined that no resourceprotection is currently in force for the selected resource. Theintermediate system 750 may send the resource protection protocol typeand one or more location codes to the resource protection system 734through the third API 1706 described above (1802). In response, theresource protection system 734-1 can send user interface data to theintermediate system 750 if the resource protection system 734-1determines that it can provide the requested resource protectionprotocol (1804).

After receiving user interface data, the intermediate system 750 cancollect information that is descriptive of the user (name, address,identifying numbers, birth date, and so forth), and/or information thatis descriptive of the resource (address, size, value, year, and soforth). This information may be retrieved from the cloud system 106,where such information is securely stored and not typically available tothe intermediate system 750 (1806). This information may be encryptedinto an encrypted key and sent to the client device 724 along with theuser interface data (1808).

As described above in relation to FIG. 15, the user interface on theclient device 724 may display the identifiers for various resourceprotection systems 734, along with user interface information. Inresponse, the user may select a particular resource protection system734-1 and request resource protection. In response, the client device724 may send the request for resource protection along with theencrypted key back to the intermediate system 750 (1810). Theintermediate system can then decrypt the encrypted key and package theinformation from the encrypted key into a transmission for the resourceprotection system 734-1. The information in the encrypted key mayinclude the personal/resource information that may be required by theresource protection system 734-1 as part of a request to provideresource protection for the particular resource. By sending theencrypted key back to the client device 724, the intermediate system 750does not need to store the encrypted key or any personal identifyinginformation or resource-specific information at the intermediate system750.

The resource protection system 734-1 may receive the data set from theintermediate system 750 and use that data set to populate a web form.The resource protection system 734-1 can then send a custom URL to theintermediate system 750 (1814), where it can be forwarded to the clientdevice 724 (1816). The custom URL can then redirect the browser of theclient device 724 to the resource protection system 734-1. Once opened,the URL will display a web form that is already pre-populated with theinformation from the encrypted key. The user can then accept theinformation and submit the formal request/application for resourceprotection.

Data Center Computer System

FIG. 19 illustrates data center computer system 1900 that may be used toimplement any of the systems described above. As shown in the figure,computer system 1900 includes a processing unit 1904 that communicateswith a number of peripheral subsystems via a bus subsystem 1902. Theseperipheral subsystems may include a processing acceleration unit 1906,an I/O subsystem 1908, a storage subsystem 1918 and a communicationssubsystem 1924. Storage subsystem 1918 includes tangiblecomputer-readable storage media 1922 and a system memory 1910.

Bus subsystem 1902 provides a mechanism for letting the variouscomponents and subsystems of computer system 1900 communicate with eachother as intended. Although bus subsystem 1902 is shown schematically asa single bus, alternative embodiments of the bus subsystem may utilizemultiple buses. Bus subsystem 1902 may be any of several types of busstructures including a memory bus or memory controller, a peripheralbus, and a local bus using any of a variety of bus architectures. Forexample, such architectures may include an Industry StandardArchitecture (ISA) bus, Micro Channel Architecture (MCA) bus, EnhancedISA (EISA) bus, Video Electronics Standards Association (VESA) localbus, and Peripheral Component Interconnect (PCI) bus, which can beimplemented as a Mezzanine bus manufactured to the IEEE P1386.1standard.

Processing unit 1904, which can be implemented as one or more integratedcircuits (e.g., a conventional microprocessor or microcontroller),controls the operation of computer system 1900. One or more processorsmay be included in processing unit 1904. These processors may includesingle core or multicore processors. In certain embodiments, processingunit 1904 may be implemented as one or more independent processing units1932 and/or 1934 with single or multicore processors included in eachprocessing unit. In other embodiments, processing unit 1904 may also beimplemented as a quad-core processing unit formed by integrating twodual-core processors into a single chip.

In various embodiments, processing unit 1904 can execute a variety ofprograms in response to program code and can maintain multipleconcurrently executing programs or processes. At any given time, some orall of the program code to be executed can be resident in processor(s)1904 and/or in storage subsystem 1918. Through suitable programming,processor(s) 1904 can provide various functionalities described above.Computer system 1900 may additionally include a processing accelerationunit 1906, which can include a digital signal processor (DSP), aspecial-purpose processor, and/or the like.

I/O subsystem 1908 may include user interface input devices and userinterface output devices. User interface input devices may include akeyboard, pointing devices such as a mouse or trackball, a touchpad ortouch screen incorporated into a display, a scroll wheel, a click wheel,a dial, a button, a switch, a keypad, audio input devices with voicecommand recognition systems, microphones, and other types of inputdevices. User interface input devices may include, for example, motionsensing and/or gesture recognition devices such as the Microsoft Kinect®motion sensor that enables users to control and interact with an inputdevice, such as the Microsoft Xbox® 360 game controller, through anatural user interface using gestures and spoken commands. Userinterface input devices may also include eye gesture recognition devicessuch as the Google Glass® blink detector that detects eye activity(e.g., ‘blinking’ while taking pictures and/or making a menu selection)from users and transforms the eye gestures as input into an input device(e.g., Google Glass®). Additionally, user interface input devices mayinclude voice recognition sensing devices that enable users to interactwith voice recognition systems (e.g., Siri® navigator), through voicecommands.

User interface input devices may also include, without limitation, threedimensional (3D) mice, joysticks or pointing sticks, gamepads andgraphic tablets, and audio/visual devices such as speakers, digitalcameras, digital camcorders, portable media players, webcams, imagescanners, fingerprint scanners, barcode reader 3D scanners, 3D printers,laser rangefinders, and eye gaze tracking devices. Additionally, userinterface input devices may include, for example, medical imaging inputdevices such as computed tomography, magnetic resonance imaging,position emission tomography, medical ultrasonography devices. Userinterface input devices may also include, for example, audio inputdevices such as MIDI keyboards, digital musical instruments and thelike.

User interface output devices may include a display subsystem, indicatorlights, or non-visual displays such as audio output devices, etc. Thedisplay subsystem may be a cathode ray tube (CRT), a flat-panel device,such as that using a liquid crystal display (LCD) or plasma display, aprojection device, a touch screen, and the like. In general, use of theterm “output device” is intended to include all possible types ofdevices and mechanisms for outputting information from computer system1900 to a user or other computer. For example, user interface outputdevices may include, without limitation, a variety of display devicesthat visually convey text, graphics and audio/video information such asmonitors, printers, speakers, headphones, automotive navigation systems,plotters, voice output devices, and modems.

Computer system 1900 may comprise a storage subsystem 1918 thatcomprises software elements, shown as being currently located within asystem memory 1910. System memory 1910 may store program instructionsthat are loadable and executable on processing unit 1904, as well asdata generated during the execution of these programs.

Depending on the configuration and type of computer system 1900, systemmemory 1910 may be volatile (such as random access memory (RAM)) and/ornon-volatile (such as read-only memory (ROM), flash memory, etc.) TheRAM typically contains data and/or program modules that are immediatelyaccessible to and/or presently being operated and executed by processingunit 1904. In some implementations, system memory 1910 may includemultiple different types of memory, such as static random access memory(SRAM) or dynamic random access memory (DRAM). In some implementations,a basic input/output system (BIOS), containing the basic routines thathelp to transfer information between elements within computer system1900, such as during start-up, may typically be stored in the ROM. Byway of example, and not limitation, system memory 1910 also illustratesapplication programs 1912, which may include client applications, Webbrowsers, mid-tier applications, relational database management systems(RDBMS), etc., program data 1914, and an operating system 1916. By wayof example, operating system 1916 may include various versions ofMicrosoft Windows®, Apple Macintosh®, and/or Linux operating systems, avariety of commercially-available UNIX® or UNIX-like operating systems(including without limitation the variety of GNU/Linux operatingsystems, the Google Chrome® OS, and the like) and/or mobile operatingsystems such as iOS, Windows® Phone, Android® OS, BlackBerry® 10 OS, andPalm® OS operating systems.

Storage subsystem 1918 may also provide a tangible computer-readablestorage medium for storing the basic programming and data constructsthat provide the functionality of some embodiments. Software (programs,code modules, instructions) that when executed by a processor providethe functionality described above may be stored in storage subsystem1918. These software modules or instructions may be executed byprocessing unit 1904. Storage subsystem 1918 may also provide arepository for storing data used in accordance with the presentinvention.

Storage subsystem 1900 may also include a computer-readable storagemedia reader 1920 that can further be connected to computer-readablestorage media 1922. Together and, optionally, in combination with systemmemory 1910, computer-readable storage media 1922 may comprehensivelyrepresent remote, local, fixed, and/or removable storage devices plusstorage media for temporarily and/or more permanently containing,storing, transmitting, and retrieving computer-readable information.

Computer-readable storage media 1922 containing code, or portions ofcode, can also include any appropriate media known or used in the art,including storage media and communication media, such as but not limitedto, volatile and non-volatile, removable and non-removable mediaimplemented in any method or technology for storage and/or transmissionof information. This can include tangible computer-readable storagemedia such as RAM, ROM, electronically erasable programmable ROM(EEPROM), flash memory or other memory technology, CD-ROM, digitalversatile disk (DVD), or other optical storage, magnetic cassettes,magnetic tape, magnetic disk storage or other magnetic storage devices,or other tangible computer readable media. This can also includenontangible computer-readable media, such as data signals, datatransmissions, or any other medium which can be used to transmit thedesired information and which can be accessed by computing system 1900.

By way of example, computer-readable storage media 1922 may include ahard disk drive that reads from or writes to non-removable, nonvolatilemagnetic media, a magnetic disk drive that reads from or writes to aremovable, nonvolatile magnetic disk, and an optical disk drive thatreads from or writes to a removable, nonvolatile optical disk such as aCD ROM, DVD, and Blu-Ray® disk, or other optical media.Computer-readable storage media 1922 may include, but is not limited to,Zip® drives, flash memory cards, universal serial bus (USB) flashdrives, secure digital (SD) cards, DVD disks, digital video tape, andthe like. Computer-readable storage media 1922 may also include,solid-state drives (SSD) based on non-volatile memory such asflash-memory based SSDs, enterprise flash drives, solid state ROM, andthe like, SSDs based on volatile memory such as solid state RAM, dynamicRAM, static RAM, DRAM-based SSDs, magnetoresistive RAM (MRAM) SSDs, andhybrid SSDs that use a combination of DRAM and flash memory based SSDs.The disk drives and their associated computer-readable media may providenon-volatile storage of computer-readable instructions, data structures,program modules, and other data for computer system 1900.

Communications subsystem 1924 provides an interface to other computersystems and networks. Communications subsystem 1924 serves as aninterface for receiving data from and transmitting data to other systemsfrom computer system 1900. For example, communications subsystem 1924may enable computer system 1900 to connect to one or more devices viathe Internet. In some embodiments communications subsystem 1924 caninclude radio frequency (RF) transceiver components for accessingwireless voice and/or data networks (e.g., using cellular telephonetechnology, advanced data network technology, such as 3G, 4G or EDGE(enhanced data rates for global evolution), WiFi (IEEE 802.11 familystandards, or other mobile communication technologies, or anycombination thereof), global positioning system (GPS) receivercomponents, and/or other components. In some embodiments communicationssubsystem 1924 can provide wired network connectivity (e.g., Ethernet)in addition to or instead of a wireless interface.

In some embodiments, communications subsystem 1924 may also receiveinput communication in the form of structured and/or unstructured datafeeds 1926, event streams 1928, event updates 1930, and the like onbehalf of one or more users who may use computer system 1900.

By way of example, communications subsystem 1924 may be configured toreceive data feeds 1926 in real-time from users of social networksand/or other communication services such as Twitter® feeds, Facebook®updates, web feeds such as Rich Site Summary (RSS) feeds, and/orreal-time updates from one or more third party information sources.

Additionally, communications subsystem 1924 may also be configured toreceive data in the form of continuous data streams, which may includeevent streams 1928 of real-time events and/or event updates 1930, thatmay be continuous or unbounded in nature with no explicit end. Examplesof applications that generate continuous data may include, for example,sensor data applications, financial tickers, network performancemeasuring tools (e.g. network monitoring and traffic managementapplications), clickstream analysis tools, automobile trafficmonitoring, and the like.

Communications subsystem 1924 may also be configured to output thestructured and/or unstructured data feeds 1926, event streams 1928,event updates 1930, and the like to one or more databases that may be incommunication with one or more streaming data source computers coupledto computer system 1900.

Computer system 1900 can be one of various types, including a handheldportable device (e.g., an iPhone® cellular phone, an iPad® computingtablet, a PDA), a wearable device (e.g., a Google Glass® head mounteddisplay), a PC, a workstation, a mainframe, a kiosk, a server rack, orany other data processing system.

Due to the ever-changing nature of computers and networks, thedescription of computer system 1900 depicted in the figure is intendedonly as a specific example. Many other configurations having more orfewer components than the system depicted in the figure are possible.For example, customized hardware might also be used and/or particularelements might be implemented in hardware, firmware, software (includingapplets), or a combination. Further, connection to other computingdevices, such as network input/output devices, may be employed. Based onthe disclosure and teachings provided herein, a person of ordinary skillin the art will appreciate other ways and/or methods to implement thevarious embodiments.

In the foregoing description, for the purposes of explanation, numerousspecific details were set forth in order to provide a thoroughunderstanding of various embodiments of the present invention. It willbe apparent, however, to one skilled in the art that embodiments of thepresent invention may be practiced without some of these specificdetails. In other instances, well-known structures and devices are shownin block diagram form.

The foregoing description provides exemplary embodiments only, and isnot intended to limit the scope, applicability, or configuration of thedisclosure. Rather, the foregoing description of the exemplaryembodiments will provide those skilled in the art with an enablingdescription for implementing an exemplary embodiment. It should beunderstood that various changes may be made in the function andarrangement of elements without departing from the spirit and scope ofthe invention as set forth in the appended claims.

Specific details are given in the foregoing description to provide athorough understanding of the embodiments. However, it will beunderstood by one of ordinary skill in the art that the embodiments maybe practiced without these specific details. For example, circuits,systems, networks, processes, and other components may have been shownas components in block diagram form in order not to obscure theembodiments in unnecessary detail. In other instances, well-knowncircuits, processes, algorithms, structures, and techniques may havebeen shown without unnecessary detail in order to avoid obscuring theembodiments.

Also, it is noted that individual embodiments may have beeen describedas a process which is depicted as a flowchart, a flow diagram, a dataflow diagram, a structure diagram, or a block diagram. Although aflowchart may have described the operations as a sequential process,many of the operations can be performed in parallel or concurrently. Inaddition, the order of the operations may be re-arranged. A process isterminated when its operations are completed, but could have additionalsteps not included in a figure. A process may correspond to a method, afunction, a procedure, a subroutine, a subprogram, etc. When a processcorresponds to a function, its termination can correspond to a return ofthe function to the calling function or the main function.

The term “computer-readable medium” includes, but is not limited toportable or fixed storage devices, optical storage devices, wirelesschannels and various other mediums capable of storing, containing, orcarrying instruction(s) and/or data. A code segment ormachine-executable instructions may represent a procedure, a function, asubprogram, a program, a routine, a subroutine, a module, a softwarepackage, a class, or any combination of instructions, data structures,or program statements. A code segment may be coupled to another codesegment or a hardware circuit by passing and/or receiving information,data, arguments, parameters, or memory contents. Information, arguments,parameters, data, etc., may be passed, forwarded, or transmitted via anysuitable means including memory sharing, message passing, token passing,network transmission, etc.

Furthermore, embodiments may be implemented by hardware, software,firmware, middleware, microcode, hardware description languages, or anycombination thereof. When implemented in software, firmware, middlewareor microcode, the program code or code segments to perform the necessarytasks may be stored in a machine readable medium. A processor(s) mayperform the necessary tasks.

In the foregoing specification, aspects of the invention are describedwith reference to specific embodiments thereof, but those skilled in theart will recognize that the invention is not limited thereto. Variousfeatures and aspects of the above-described invention may be usedindividually or jointly. Further, embodiments can be utilized in anynumber of environments and applications beyond those described hereinwithout departing from the broader spirit and scope of thespecification. The specification and drawings are, accordingly, to beregarded as illustrative rather than restrictive.

What is claimed is:
 1. A method of verifying resource protectionstatuses for resources for address-based resources, the methodcomprising: receiving, by an intermediate system, a request forverification of resource protection from a client device for anaddress-based resource, wherein: the request comprises an address of aresource; the intermediate system is programmed to receive resourceprotection verification requests from a plurality of client devices, andto receive resource protection verifications from a plurality ofresource protection systems that are in communication with theintermediate system; determining, by the intermediate system, that noneof the resource protection systems in the plurality of resourceprotection systems currently protect the resource; sending, by theintermediate system, an indication to the client device that theresource is currently unprotected; receiving, by the intermediatesystem, an indication from the client device that protection for theresource should be requested; retrieving, by the intermediate system,information that is securely stored for the resource and a userassociated with the request; and sending, by the intermediate system,the information to one or more of the plurality of resource protectionsystems as a request to protect the resource.
 2. The method of claim 1,wherein the intermediate system acts as an intermediary to decouplerequests from client devices from requests sent to the plurality ofresource protection systems.
 3. The method of claim 1, wherein theintermediate system comprises a cloud-based system that operates onhardware and software that is different from any of the plurality ofresource protection systems.
 4. The method of claim 1, wherein theaddress of the resource comprises a physical location of the resource.5. The method of claim 1, wherein the indication from the client devicethat the resource is currently unprotected comprises a list of one ormore resource protection systems from the plurality of resourceprotection systems.
 6. The method of claim 5, wherein an order of thelist of one or more resource protection systems is determined based on apredetermined priority level for each of the one or more resourceprotection systems.
 7. The method of claim 5, wherein an order of thelist of one or more resource protection systems is determined based on apreference indicated by the user.
 8. The method of claim 1, furthercomprising: receiving, by the intermediate system, a second request forverification of resource protection from a second client device for asecond address-based resource; determining, by the intermediate system,that one or more of the resource protection systems in the plurality ofresource protection systems currently protect the resource; and sendingan transmission to the one or more of the resource protection systemsindicating that the resource is being transferred to the user from aprevious user.
 9. The method of claim 1, wherein information that issecurely stored by the intermediate system comprises contact informationfor the user and the address of the resource.
 10. A system comprising:one or more processors; and one or more memory devices comprisinginstructions that, when executed by the one or more processors, causethe one or more processors to perform operations comprising: receiving,at an intermediate system, a request for verification of resourceprotection from a client device for an address-based resource, wherein:the request comprises an address of a resource; the intermediate systemis programmed to receive resource protection verification requests froma plurality of client devices, and to receive resource protectionverifications from a plurality of resource protection systems that arein communication with the intermediate system; determining, by theintermediate system, that none of the resource protection systems in theplurality of resource protection systems currently protect the resource;sending, by the intermediate system, an indication to the client devicethat the resource is currently unprotected; receiving, by theintermediate system, an indication from the client device thatprotection for the resource should be requested; retrieving, by theintermediate system, information that is securely stored by theintermediate system for the resource and a user associated with therequest; and sending, by the intermediate system, the information to oneor more of the plurality of resource protection systems as a request toprotect the resource.
 11. The system of claim 10, wherein the operationsfurther comprise: authorizing, by the intermediate system, the pluralityof resource protection systems that provide protection for a pluralityof different resources to provide periodic uploads to the intermediatesystem; receiving, by the intermediate system, periodic uploads ofinformation associated with protected resources from the plurality ofresource protection systems, wherein the information associated with theprotected resources comprises data subsets of full data sets stored atthe plurality of resource protection systems; and storing the datasubsets in a database at the intermediate system.
 12. The system ofclaim 11, wherein determining, by the intermediate system, that none ofthe resource protection systems in the plurality of resource protectionsystems currently protect the resource comprises: using the address ofthe resource, querying the database for a data subset associated withprotection of the resource.
 13. The system of claim 10, wherein theoperations further comprise: receiving an estimate of a data value forresource protection from one or more resource protection systems in theplurality of resource protection systems; and sending the estimate ofthe data value to the client device.
 14. The system of claim 10, whereinthe operations further comprise: generating an estimate of a data valuefor resource protection, wherein the estimate is based at least in parton data values received from the resource protection systems; andsending the estimate of the data value to the client device.
 15. Thesystem of claim 10, wherein the operations further comprise sending asecond request based on the request for verification of resourceprotection to a subset of the plurality of resource protection systems,wherein the second request is sent in response to receiving the requestfor verification of resource protection.
 16. The system of claim 14,wherein the operations further comprise reformatting the request forverification of resource protection into a standard format for an APIused by the plurality of resource protection systems and specified bythe intermediate system.
 17. The system of claim 10, wherein anindication of resource protection received from one of the plurality ofresource protection systems comprises: a protection start time; and aprotection interval.
 18. The system of claim 10, wherein the informationthat is securely stored by the intermediate system for the resource andthe user associated with the request is used to populate a form.
 19. Anon-transitory, computer-readable medium comprising instructions that,when executed by one or more processors, cause the one or moreprocessors to perform operations comprising: receiving, at anintermediate system, a request for verification of resource protectionfrom a client device for an address-based resource, wherein: the requestcomprises an address of a resource; the intermediate system isprogrammed to receive resource protection verification requests from aplurality of client devices, and to receive resource protectionverifications from a plurality of resource protection systems that arein communication with the intermediate system; determining, by theintermediate system, that none of the resource protection systems in theplurality of resource protection systems currently protect the resource;sending, by the intermediate system, an indication to the client devicethat the resource is currently unprotected; receiving, by theintermediate system, an indication from the client device thatprotection for the resource should be requested; retrieving, by theintermediate system, information that is securely stored by theintermediate system for the resource and a user associated with therequest; and sending, by the intermediate system, the information to oneor more of the plurality of resource protection systems as a request toprotect the resource.